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ABSTRACT 


This thesis describes a methodology used to develop a systems engineering (SE) 
competency framework for Space and Naval Warfare Systems Center (SSC) Atlantic—a 
Department of Navy organization whose vision statement is to “Make IT count for the 
Warfighter and the Nation.” This methodology defines the role of systems engineers at 
SSC Atlantic; establishes prioritized SE competency areas; identifies associated 
knowledge, skills and abilities (KSAs); identifies optimal workforce development 
methods for each KSA; and addresses how to assess systems engineers against a 
competency development model. 

The results of this analysis show that systems engineers require many of the same 
KSAs as other members of the engineering workforce, but also require unique KSAs 
focused on customer mission/capability areas, technology areas, SE processes/activities 
and leadership skills. Developmental methods for systems engineers to obtain these 
KSAs range from informal on-the-job training to professional certifications and degrees. 
The methodology established in this thesis can be used by other organizations to develop 
and employ their own competency framework in practically any discipline. The SE 
competency framework defined in this thesis can be leveraged/tailored by other SE 
organizations in order to establish developmental roadmaps for improving the KSAs of 
their workforce. 
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EXECUTIVE SUMMARY 


This thesis examines how to build and employ a framework for developing the 
competency of systems engineers at a Department of Defense (DoD) organization such as 
Space and Naval Warfare Systems Center (SSC) Atlantic. While there are many high- 
level government and industry models for systems engineering (SE) competency 
development, few provide a comprehensive, prioritized set of knowledge, skills and 
abilities (KSAs), recommendations on how to actually develop systems engineers and 
insight into how systems engineering competency might be assessed. Furthermore, there 
is little understanding of the various types of systems engineers at an information 
technology-centric DoD organization and how their skillsets may need to differ. This 
thesis examines the various types of systems engineering competency areas and 
associated KSAs defined by Defense Acquisition University (DAU), National 
Aeronautics and Space Administration, International Council on Systems Engineering 
and Naval systems engineering competency models. It also examines those competency 
and KSA areas that are of particular importance to SSC Atlantic, such as those defined by 
the National Institute of Standards and Technology in the National Cybersecurity 
Workforce Framework. This paper analyzes various forms of education and training that 
can be used to support the development of systems engineering KSAs and when they are 
most appropriate. 

The results of this thesis show that, in order to properly develop a SE workforce 

in an IT command such as SSC Atlantic, one must first understand what competency 

areas and KSAs systems engineers must attain. A SE competency framework should 

consider the SE life cycle processes, and also technology areas, mission/capability areas 

and leadership skills to ensure that systems engineers are well rounded in order to provide 

technical leadership to multi-disciplinary teams with role-diverse team members. When 

establishing a competency framework, careful consideration should be made toward 

which precise use case(s) will be supported by the framework. Identifying relevant and 

authoritative competency area and KSA sources for the competency framework is also 

critical, as there is no need to recreate data that has already been adequately developed by 

xvii 



several other relevant and established industry and DoD organizations. When prioritizing 
competency areas and KSAs, each SE use case must be considered separately as each 
will likely emphasize different competency areas. Competency areas such as stakeholder 
requirements definition, requirements analysis, architecture design, software engineering, 
acquisition, verification and system assurance require more emphasis at SSC Atlantic 
than others. In order to establish systems engineering roles that can be well understood 
across the organization, one must examine the roles that will interact with the role of a 
systems engineer in order to determine where KSAs will be shared across the roles or 
unique to one or the other. 

Analysis must also be conducted to understand how these KSAs can and should 
be obtained. The most common methods for developing SE KSAs are through 
educational training (DAU, degrees or certifications), in-house-developed training 
courses/workshops, and on-the-job training (OJT). DAU Systems Planning, Research, 
Development & Engineering—SE classes can be effective when providing systems 
engineers with basic knowledge and comprehension of the SE life cycle processes— 
particularly in the areas of acquisition and risk management. Leadership skills can be 
developed through programs, such as the Mid-Career Leadership and Mentorship 
Programs. OJT can be enhanced when coupled with targeted rotational and job 
shadowing opportunities. If approached systematically, immeasurable value can be 
obtained from developing in-house SE training that engages systems engineers at all 
levels of the workforce. The Graduate Reference Curriculum for Systems Engineering 
provides useful, tailorable recommendations on how to develop and assess SE curricula. 
When it comes to assessing the competency of systems engineers, care must be taken to 
choose an assessment process and associated assessment methodologies that are 
relatively thorough yet not overly cumbersome, time-consuming and costly. 

This thesis goes through the process of establishing a SE competency framework 
for SSC Atlantic that can easily be tailored for other SE-focused organizations. The 
process begins by defining the role(s) of systems engineers within the organization. Then 
existing competency frameworks are examined in order leverage existing best practices. 



Competency areas (or KSA groupings) are examined and prioritized based on how 
systems engineering should be conducted in the most likely project use cases. 

Once the basic requirements for the competency framework are established, then 
a competency framework is built to address a complete set of competency areas and 
KSAs desired for systems engineers within an organization. Alternative methods are 
defined for developing competency. Criteria are established to determine optimal 
methods for developing different types of KSAs. This allows for each systems engineer 
KSA to be mapped to optimal development methods. Finally, a manner for assessing 
systems engineers is developed and executed in order to track each systems engineer’s 
progression in terms of proficiency. 
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I. INTRODUCTION 


A. BACKGROUND 

Since the inception of the field of systems engineering, corporations and 
government organizations worldwide have been trying to figure out what knowledge, 
skills and abilities (KSAs) are most crucial for practicing systems engineers. 
Competency models, such as the systems planning, research, development and 
engineering—systems engineering/program systems engineering (SPRDE-SE/PSE) 
competency model developed by Defense Acquisition University (DAU) and the project 
management and systems engineering competency framework developed by the National 
Aeronautics and Space Administration (NASA) help frame what KSAs are most needed 
in order to effectively perform systems engineering (see NASA, 2012 and DAU SPRDE- 
SE/PSE Competency Model, 2009). As the systems being engineered continue to evolve 
and become more complex, some competency models, such as the International Council 
on Systems Engineering (INCOSE) systems engineering competency framework have 
also evolved in order to address system complexity throughout the systems engineering 
life cycle (International Council on Systems Engineering [INCOSE], 2010). 

Today the challenge does not lie as much in developing or adopting a competency 
model for an organization tasked with delivering complex systems, as there are many 
overarching and industry-standard models from which to choose. Rather, the greater 
challenge is figuring out how to tailor and employ existing competency models in order 
to develop individuals’ KSAs in an effective and cost-efficient manner. In other words, 
how do we know which competency areas and KSAs are most critically needed to 
perform systems engineering? What are the variables in systems engineering that drive 
the importance of the various systems engineering (SE) competency areas? What 
methods should be employed to develop KSAs in systems engineers—on-the-job training 
(OJT), in-house classroom training, vendor-provided training, undergraduate or graduate 
programs, etc.? Under what circumstances is each method most appropriate? 
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B. PURPOSE 


The purpose of this thesis is to understand what type of competency framework 
Space and Naval Warfare Systems Center (SSC) Atlantic should employ in order to 
develop its systems engineers. This will be achieved by synthesizing together elements 
from industry and government-standard competency models that have been generated by 
organizations external to SSC Atlantic. This will also include drawing from legacy 
competency models employed by SSC Atlantic over the last five years. This thesis aims 
to determine what types of education and training (structured and unstructured) can best 
be used to maximize the effectiveness of systems engineers. 

More specifically, this thesis will examine various types of systems engineering 
competency areas and associated KSAs defined by DAU, NASA, and INCOSE 
competency models. This thesis will also look closely at the Naval Systems Engineering 
(SE) Competency Development Model (CDM), which itself is tailored from a strong 
pedigree of various organizations’ SE competency frameworks—those of NASA, DAU 
and INCOSE, but also of Boeing and the Naval Underwater Warfare Center, Newport. 
This thesis will also examine those competency and KSA areas that are of particular 
importance to SSC Atlantic, such as those defined by the National Institute of Standards 
and Technology (NIST) in the national cybersecurity workforce framework (NCWF). 
The Graduate Reference Curriculum for Systems Engineering (GRCSE) will also be 
examined to determine how it can be applied in order to employ a newly-tailored SSC 
Atlantic SE CDM. 

C. RESEARCH QUESTIONS 

1. What competency areas and associated KSAs are particularly applicable to 
SSC Atlantic systems engineers? 

2. How can the GRCSE be used to effectively employ a CDM? 

3. How do various forms of education and training best support the 
development of KSAs required to develop competent systems engineers at 
SSC Atlantic? 
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D. BENEFITS OF STUDY 


This thesis is intended to provide recommendations to the leadership of 
Department of Defense (DoD) IT organizations on how to best approach competency 
development and the delivery of systems engineering education, training and other forms 
of developmental opportunities to their engineering workforce. More specifically, the 
Space and Naval Warfare Command (SPAWAR) and its systems centers—SSC Atlantic 
and SSC Pacific—as well as similar organizations should benefit from these analyses and 
recommendations. These recommendations will be used to shape future SE course 
learning objectives and competency development models employed by SPAWAR. The 
recommendations should assist in making better decisions on where to spend workforce 
development training funds in an increasingly budget-constrained DoD environment. 
This thesis will also provide an approach toward tailoring and employing competency 
development models for a DoD organization whose primary mission is to deliver 
complex IT solutions to a diverse base of end users. 

E. SCOPE AND METHODOLOGY 

This thesis seeks to develop a competency framework that can be directly used by 
SSC Atlantic to develop various types of systems engineers. This framework defines 
how CDMs are structured and employed in terms such as competency vectors and 
competency areas. Each individual CDM within the framework is based upon different 
systems engineering use cases and will define the associated KSAs categorized by 
competency stages, or levels. The methodology depicted in Eigure 1 is employed in 
order to develop this overarching SE competency framework. 
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Step 1: Define the role{s) of systems 


Step 7: Develop and assess 

engineers at SSC Atlantic 


systems engineers 


step 2i Identify existing competency model 
frame works re I event to SSC Atlantic 


Step 3i identify and prioritize competency 
areas and KSAs that are applicable to SSC 
Atlantic 


Step 6; Map KSAs to optimal 
wo r kf o r ce d evelop ment 
methods 

_ L _ 

Step 5: Identifv alternative 
methods for developing KSAs 


Step 4: Design and build a tailored 
competency framework that 
addresses a complete set of 
competency areas and KSAs desired 
for systems engineers 


Figure 1. SE Competency Framework Development Methodology 


Figure 1 depicts the seven-step process applied throughout Chapters II through IV 
of this thesis in order to establish the proposed SSC Atlantic SE competency framework. 
The following section summarizes each of these steps. 

1. Define the Role(s) of Systems Engineers at SSC Atlantic 

In order to understand the role of a systems engineer, first the purpose of systems 
engineering will be examined, as well as the secondary disciplines or fields of study 
related to systems engineering that are frequently applied at SSC Atlantic. Next, the 
general role of an SSC Atlantic systems engineer will be defined, along with the different 
types of systems engineer roles, defined herein as “subroles.” 

2. Identify Existing Competency Model Frameworks 

Identifying existing SE competency frameworks will require exploration into 
models currently used by organizations such as NASA, DAU, INCOSE and, most 
importantly, the Department of Navy and U.S. Marine Corps. There are also a number of 
fields of study that overlap with systems engineering. For example, project management, 
enterprise architecture and IT service management are all fields of practice that share 
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common process areas and correlated life cycle models with systems engineering. 
Because SSC Atlantic’s mission within the DON focuses on delivering information 
technology (IT) solutions, the national cybersecurity workforce framework (NCWF) 
developed by NIST proves to be particularly relevant to the cause (National Initiative for 
Cybersecurity Education, 2013). There are also a number of leadership competencies and 
personal attributes, typically called soft skills or professional skills, such as verbal 
communication, conflict resolution and strategic thinking that enhance the proficiency 
and development of systems engineers. Exploring the KSAs associated with each of 
these fields can ultimately add value to the competency framework for a systems 
engineer. 


3. Identify and Prioritize Competency Areas and KSAs that are 
Applicable to SSC Atlantic 

Existing competency model frameworks for SE and related fields all come 
equipped with some mechanism with which to categorize KSAs. These categories, 
known as competency areas, each supply KSAs that are tailored at various competency 
level stages, which are defined in this study as entry, intermediate, advanced and expert. 
This step of the methodology first examines which competency areas from the 
frameworks identified in Steps 2 and 3 are most applicable to SSC Atlantic. 
Furthermore, specific KSAs from these competency areas are selected for inclusion into 
the SSC Atlantic competency development model. This step also involves prioritizing 
which competency areas and specific KSAs are most relevant to the role of an SSC 
Atlantic systems engineer. 

4. Design and Build a Tailored Competency Framework That Addresses 
a Complete Set of Competency Areas and KSAs Desired for Systems 
Engineers 

Once a complete set of prioritized competency areas and KSAs have been defined 
for the SSC Atlantic systems engineer, a new competency framework must be established 
which organizes competency areas and KSAs into high level competency vectors. 
Organizing this new competency framework into competency vectors will assist 
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engineering managers in communicating the general contents of the SSC Atlantic SE 
competency framework. 

5. Identify Alternative Methods for Developing KSAs 

Once a complete list of applicable competency areas and KSAs has been 
developed for SSC Atlantic systems engineers, the process for determining how 
individuals best develop these KSAs can begin. Basic methods for developing KSAs 
include OJT, educational training (degree and certification programs) and professional 
development. 


6. Map KSAs to Optimal Workforce Development Methods 

In order to determine the optimal development methods for systems engineering 
KSAs, decision criteria will be established. Using these decision criteria, each KSA in 
the newly established SSC Atlantic SE competency framework will be mapped to its 
optimal development method(s). 

7. Develop and Assess Systems Engineers 

This step will leverage the SE competency framework established in Steps 1 
through 6 in order to develop SSC Atlantic systems engineers through the entry, 
intermediate, advanced and expert stages of the CDMs most applicable to their SE 
subroles. This step will also provide a high level overview for how to assess systems 
engineers (or any other role) against the associated CDM stages. 

F. THESIS ORGANIZATION 

This thesis is organized by chapters covering the following topics; 

1. Chapter I: Introduction—describes the thesis background, purpose, the 
questions to be answered, projected benefits, methodology and content 
organization. 

2. Chapter II: Problem Definition—This chapter summarizes the relevant 
research on the problem, defines the problem statement and provides 
context for the thesis. More specifically, this chapter defines the role of 
systems engineers at SSC Atlantic (Step 1), defines key terms associated 
with competency models and identifies competency models relevant to SE 
at SSC Atlantic (Step 2). 


6 



3. Chapter III: Applying SE Competency Areas to SSC Atlantic: This 
chapter discusses how KSA data is used at SSC Atlantic. This chapter 
also examines which competency areas and KSAs described in existing 
competency frameworks are most germane to how SSC Atlantic engages 
in systems engineering (Step 3). 

4. Chapter IV: Designing a New Competency Framework for SSC Atlantic 
SE Roles and Subroles—This chapter establishes a new framework for SE 
competency development equipped with competency vectors relevant to 
the SSC Atlantic mission (Step 4). This chapter defines SSC Atlantic 
roles, subroles and their associated use cases. 

5. Chapter V: A Model for Effective Systems Engineering Workforce 
Development at SSC Atlantic—This chapter discusses how the SSC 
Atlantic competency framework can be employed using alternative 
methods for employee development of KSAs (Step 5). This chapter 
describes each workforce development method and provides 
recommendations on where each is most appropriate for developing 
systems engineering KSAs (Steps 6 and 7). The chapter concludes with 
an overview for how to assess competency or proficiency levels against a 
CDM. 

6. Chapter VI: Conclusions and Recommendations—This chapter 
summarizes the research, reiterates the key findings, and recommends 
areas for future research. 
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II. PROBLEM DEFINITION 


A. SYSTEMS ENGINEERING—THE CORE ELEMENTS 

Since its formal beginning in the mid-twentieth century, systems engineering has 
been defined and redefined several times. In 1960, Flagle, Huggins and Roy stated that 
systems engineers “engage in the analysis of complex man and machine systems or one 
may also say man and machine operations, utilize multi-discipline teams, employ the 
scientific method, emphasize the ‘whole system’ rather than the component approach” (p. 
23). This early definition wonderfully captures several of the key facets of systems 
engineering. The first key element of this definition is the concept that the human is 
actually part of the system and that systems are complex. The second point these 
pioneers make is that systems engineering requires multi-disciplinary teams. They also 
recognize the systematic or analytical approach that systems engineering must employ by 
referring to the “scientific method.” Lastly, they astutely identify the need for systems 
thinking in systems engineering, where one must take a holistic approach to solving 
system domain problems rather than over-emphasizing individual subsystems at the 
expense of the whole. 

In his 1967 definition. Chestnut went on to highlight the difference between 
operating a system and engineering a system: “the overall problem of systems 
engineering is composed of two parts, one being the systems engineering associated with 
the way that the operating system itself works and the other with the systematic process 
of performing the engineering and associated work in producing the operating system” 
(p. 12). Modern day systems engineering life cycle models do not stop once the 
“engineering” part of the process is complete. Rather, they depict the operations, 
maintenance and disposal phases of the end-to-end process as well. During the 1990s, 
Checkland built upon these concepts by defining systems engineering as “the set of 
activities that together lead to the creation of a complex man-made entity and/or the 
procedures and information flows associated with its operation” (1993, p. 138). This 
particular definition highlights the interaction between components in a system. 
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Other modem day definitions of systems engineering include: 

1. “The design of a complex interrelation of many elements (a system) to 
maximize an agreed-upon measure of system performance, taking into 
consideration all of the elements related in any way to the system, 
including utilization of worker power as well as the characteristics of each 
of the system’s components.” (Parker, 1994, p. 498) 

2. “An interdisciplinary collaborative approach to derive, evolve, and verify 
a life-cycle balanced system solution which satisfies customer 
expectations and meets public acceptability.” (Institute of Electrical and 
Electronics Engineers [IEEE] 1220, 1998, p. 11) 

3. “An interdisciplinary approach and means to enable the realization of 
successful systems.” (INCOSE, 2004, p. 12) 

In addition to the core themes of interdisciplinary teams, complexity, human 
interactions and systems thinking, systems engineering is grounded in its basic processes 
of planning (arrangement of specific steps), designing (applying scientific and 
engineering methods) and management (skillfully leveraging resources). The last two 
definitions cited above from the Institute of Electrical and Electronics Engineers (IEEE) 
and INCOSE highlight the need for systems to meet customers’ expectations and be 
“successful,” alluding to the importance of meeting stakeholder needs. 

B. PERSPECTIVES ON THE ROLE OE A SYSTEMS ENGINEER 

The primary functions of a systems engineer (one who practices systems 
engineering) can be framed in various ways. However, there are a number of common 
trends that appear in the functions associated with a systems engineer. The Systems 
Engineering Body of Knowledge (SEBoK) highlights the following primary functions of 
a systems engineer: he or she: 

• Supports an interdisciplinary approach 

• Elicits and translates customer needs into specifications 

• Supports the systems engineering life cycle processes 

• Analyzes, specifies, designs and verifies the system to ensure that its 
functional, interface, performance, physical, and other quality 
characteristics—as well as cost—are balanced to meet the needs of the 
system 

• Ensures the elements of the system fit together to accomplish the 
objectives of the whole 
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• Ultimately satisfies the needs of the customers and other stakeholders who 
will acquire and use the system (Pyster, Olwell, Hutchison, Enck, 
Anthony, Henry, & Squires, 2012, p. 5). 

The GRCSE states that the role of the systems engineer includes: 

• Understanding the intended purpose, operational context, and concept of 
use of the proposed system 

• Appreciating the interests, purposes, values of multiple stakeholders and 
combining these into a coherent representation of the system requirements. 

• Understanding the technology that may be applied in the system 

• Appreciating the life cycle implications of systems and incorporating life 
cycle perspectives into systems design 

• Evaluating, selecting, and developing system solutions to satisfy customer 
needs and project objectives (GRCSE, 2012, p. 1). 

C. DEFINING THE ROLE OF THE SYSTEMS ENGINEER AT SSC 
ATLANTIC 

Defining the KSAs required for a systems engineer in a complex organization 
such as SSC Atlantic comes with its challenges. The first challenge is defining the role 
of the systems engineer in a manner which can be accepted across a large, matrix 
organization. As of July 2013, SSC Atlantic consists of just over 4,000 U.S. government 
employees—over half of which work for the engineering department (actually known as 
the engineering “competency”). For the purposes of this paper, the SSC Atlantic 
engineering competency will be referred to as a “department” so as not to confuse it with 
the classical definition of “competency,” which will be addressed later in the paper. The 
SSC Atlantic engineering department engineers, scientists, technicians and specialists are 
all involved in systems engineering in various capacities. Over 240 integrated product 
teams (IPTs) in SSC Atlantic work to deliver various IT-related end item products to 
Naval, Joint and Coalition warfighting customers. The range of engineering processes, 
technologies, missions and customers supported by the SSC Atlantic engineering 
department covers a wide spectrum. Determining the desired competency areas and 
KSAs for a lead systems engineer on any one of these IPTs may be a relatively 
straightforward task. However, determining a common set of KSAs for a lead systems 
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engineer for all 240 IPTs becomes significantly more challenging. This task requires 
observing the common duties or responsibilities associated with all of these roles. 

In February 2013, SSC Atlantic engineering department leaders decided to 
establish the following core duties for an IPT technical lead, which is closely related to 
the role of a the lead systems engineer on an IPT: 

• Identify scope of engineering/technical tasks on an IPT 

• Determine what technical expertise is needed to support the IPT based on 
customer needs 

• Determine the roles/KSAs needed on an IPT and when to submit demand 
signals out to the appropriate competencies 

• Support/lead technical reviews for the IPT 

• Responsible for the review of engineering/technical deliverables; 
Responsible for the technical quality of the work products produced by the 
IPT 

• Work with portfolio systems engineers to integrate into enterprise 
architecture / system of systems / mission 

• Serve as technical advisors for the IPT and adhere to the latest SSC 
Atlantic technical initiatives 

An individual serving the role of an IPT technical lead may also serve as the IPT 
lead or program manager. The role of an SSC Atlantic IPT technical lead is compared to 
that of a systems engineer, as defined by the aforementioned sources in Table 1. 


Systems Engineer Role Key Concepts 

SEBoK 

GRCSE 

SSC Atlantic 

Integrating different disciplines and technologies 

X 


X 

Addressing operational / stakeholder needs 

X 

X 

X 

Systenns Engineering life cycle processes 

X 

X 

X 

Requirennents traceability through design, 

verification, validation 

X 

X 


Systenn elennents fitting together to nneet the 

objectives of the whole 

X 


X 

Satisfying custonner needs 

X 

X 


Balancing cost, schedule and perfornnance 

X 

X 



Table 1. SE Role Key Concepts Stressed by Different Organizations (After GRCSE, 

2012, p. 1; Pyster et al., 2012, p. 9) 
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Comparing the SE role perspectives of SEBoK and GRCSE, both stress the 
importance of addressing operational needs, requirements traceability, balancing the 
tradeoffs between cost, schedule and performance, satisfying customer needs and SE life 
cycle processes. When comparing the SSC Atlantic IPT technical lead role to that of the 
systems engineer (as defined by SEBoK and GRCSE), there appears to be a gap in the 
areas of requirements traceability, customer needs satisfaction and the balancing of cost, 
schedule and performance (GRCSE, 2012, p. 1; Pyster et ah, 2012, p. 9). However, there 
are other defined IPT roles within SSC Atlantic, which specifically address these three 
functional areas—the requirements engineer (who addresses requirements traceability), 
the tester (who validates user needs are met) and the project manager (who balances cost, 
schedule and performance). This frees up the IPT technical lead role to focus on areas of 
importance that are not stressed in classical systems engineering roles, such as those 
associated with scoping engineering tasks, managing engineering resources, planning 
technical reviews, and conducting technical deliverable reviews. 

D. COMPETENCY AND COMPETENCY ERAMEWORKS 

Simply understanding the basic duties that need to be performed in a role such as 
a systems engineer or a project manager is insufficient. One must also define the KSAs 
needed to perform those duties effectively and organize them in such a way for an 
individual to visualize a developmental roadmap for competency development. In order 
to understand the various competency model frameworks that can be leveraged to help 
define the developmental needs of systems engineers, one must first examine the basic 
concepts of competency and competency frameworks. The term capability refers to “the 
ability to deliver a product or service” (Holt & Perry, 2011, p. 5). In the context of this 
paper, the end goal is to improve SSC Atlantic’s ability to provide the service of 
delivering superior IT solutions through systems engineering. In other words, the goal is 
to improve SSC Atlantic’s systems engineering capability. 

The term competency is defined as “an important skill that is needed to do a job” 
(Holt & Perry, 2011, p. 2) while a competency framework “describes a set of 
competencies (the ‘things’ that are measured to demonstrate competence) that are 
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applicable to a particular field” (Holt & Perry, 2011, p. 6). For the purposes of this paper, 
competencies are referred to as competency areas. These competency areas are made up 
of various knowledge, skills, and abilities (KSAs). Figure 2 illustrates how a eompetency 
framework ean be subdivided into multiple competeney areas, eaeh of whieh contains 
any number of KSAs. KSAs can be developed via a number of workforce development 
methods. Professional development, OJT and other forms of workforce development 
methods are further defined and diseussed in Chapter V. Competency models and 
frameworks also eome equipped with “a seale for assessing the level of individual 
proficiency in each competency” (Pyster et al., 2012, p. 694). 


Competency 

Framework 


Competency 
Area #1 


Competency 
Area #2 


Competency 
Area #3 





KSA#1.1 


KSA #2.1 


KSA #3.1 




KSA #1.2 


KSA #2.2 


KSA #3.2 

« 


* 


* 

« 

m 

* 

* 

KSA #1.X 


KSA #2.X 


KSA #3.X 


Figure 2. Basic Competency Framework with Associated Competeney Areas 

and KSAs 

When applied to systems engineering, KSAs can be eharaeterized by groups of 
competency areas known as competency vectors or dimensions. Example competency 
vectors include systems engineering life cycle phase, product type, engineering discipline 
or mission area. The SEBoK asserts, “SE eompeteney must be viewed through its 

relationship to the systems life eyele, the SE discipline, and the domain in whieh the 
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engineer practices SE” (Pyster et al., 2012, p. 694). Each of these perspectives may be its 
own competency vector. Eigure 3 illustrates how competency vectors allow for the 
grouping of competency areas. 


Competency Framework 


Competency Vector A 


Competency Vector B 


Competency 
Area Al 


Competency 
Area A2 


Competency 
Area A3 


Competency 
Area B1 


Competency 
Area B2 


Competency 
Area B3 







KSAAl.l 


KSA A2.1 


KSA A3.1 


KSA Bl.l 


KSA B2.1 


KSA B3.1 







KSA A1.2 


KSA A2.2 


KSA A3.2 


KSA B1.2 


KSA B2.2 


KSA B3.2 




















KSA Al.X 


KSA A2.X 


KSA A3.X 


KSA Bl.X 


KSA B2.X 


KSA B3.X 


Figure 3. Competency Framework Employing Competency Vectors 


E. SE COMPETENCY MODEL USE CASES 

The SEBoK states that, “SE competency models can be used to explicitly state 
and actively manage the SE competencies within an organization” (Pyster et al., 2012, 
p. 694). More specifically, these competency models are useful in a number of 
organizational processes—namely hiring, IPT staffing, organizational capability 
development, and individual competency development. Appendix A depicts the process 
model for each of these. These organizational processes, or use cases are summarized as 
such: 


• Hiring —KSAs defined in a competency model can be used throughout 

the recruiting and hiring process in order to fill needed positions. 
Potential candidates for employment that are assessed at higher CDM 
stages or with more of the requisite KSAs would be more likely to be 
selected/hired for systems engineering positions. 
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• IPX staffing —The IPT staffing process begins with an external 
customer’s need for SE services. The IPT Lead then works with other 
members of engineering department management to determine what roles, 
subroles and KSAs are needed in order to provide those services. The 
appropriate engineering supervisors then use each employee’s KSA data 
to determine who is the most capable of providing those needed services 
for a particular IPT assignment. 

• Organizational capability development & training identiflcation— 

Engineering department managers can look across the aggregate 
workforce to determine where employees are most competent (where they 
have the KSAs) and where they need further development (where they 
don’t have the KSAs) in order to satisfy present and future demand for SE 
services. These KSA gaps in the workforce become priority competency 
areas where optimal workforce development methods should be identified 
and executed. Eor example, if a large portion of the engineering 
department workforce lacks the requisite KSAs to perform interface 
management, then a potential solution would be to develop or acquire 
structured interface management training that would address this 
capability gap. 

• Individual competency development —Individuals understand which 
competency areas and KSAs they need to develop in order to advance 
through the entry, intermediate, advanced and expert stages of their SE 
role competency development model. 

F. EXISTING SE COMPETENCY FRAMEWORKS 

Within the DoD and industry, there are a number of existing SE competency 
frameworks that describe SE competency areas and associated KSAs. The SEBoK 
discusses and summarizes the SE competency models employed by INCOSE, MITRE, 
DAU, NASA, the Software Engineering Institute (SEI) and the capability maturity model 
integration (CMMI) as shown in Table 2. Each of these five competency models is 
relatively young, as the earliest (those of SEI and MITRE) were authored in 2007. 
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( ompetcncy .Model 

Individual Level 

Date 

.\uthor(s) 

Purpose 

Development .Method 

(ompetency 

.Model 

IN( osi: I K \V(; 

2010 

INCOSE 

Identify the competencies required to conduct 
good sy.stems engineering 

INCOSE Working Group 

INCOSE (2010) 

.Mi l RL C'ompelency 

.Model 

2007 

MITRE 

To define new curricula systems engineering and 
to as.sess personnel and organizational 
capabilities 

Focus groups as de.scribed 
in Trudeau (2005) 

Trudeau (2(X)5), 

MITRE 2007 

SI*R1)K-SF7PSK 

( ompetency .Model 

2010 

DAU 

A.ssess U.S. DoD Civilian acquisition workforce 
capabilities 

DoD and DAU internal 

development 

DAU (2010) 

.\I*PLL ('ompeteney 

.Model 

2009 

NASA 

To improve project management management 
and systems engineering at NASA 

NASA internal 

development 

APPEL (2(X)9) 

( .M.MI for Development 

2007 

SEl 

Process improvement maturity model for the 
development of products and services 

SEl Internal Development 

SEl (2007) 


Table 2. Summary of SE Competency Models (From Pyster et al., 2012, p. 696) 


Rather than compare and contrast all five models, the three arguably most 
relevant to SSC Atlantic systems engineering will be discussed—DAU, NASA and 
INCOSE. The DAU SPRDE-SE/PSE competency model is the most highly correlated 
model as it is used DoD-wide and SSC Atlantic is a DoD/DON engineering and 
acquisition organization. As of April 2013, 878 SSC Atlantic employees were designated 
as being in a DAU SPRDE-SE/PSE billet. NASA—a Federal organization—has been a 
pioneer in the field of SE for decades. NASA offers a mature SE competency framework 
(known as the Academy of Program/Project Engineering Leadership (APPEL) 
competency model) centered on engineering and delivering complex systems. Therefore, 
the NASA APPEL model is largely relevant to the types of services that are provided at 
SSC Atlantic. The INCOSE model is perhaps the most pervasive competency model and 
is embraced by many members of the international SE community. INCOSE’s SE 
competency model is closely correlated with those of DAU, NASA and other 
Federal/DoD organizations, but also offers industry’s best-of-breed representation of a 
SE competency framework. INCOSE also administers the most well-known SE 
certification program in the world—Certified Systems Engineering Professional (CSEP). 

While not discussed in this thesis, it should be noted that the Project Management 
Institute (PMI) and skills framework for the information age (SFIA) offer competency 
models in the areas of project/program management and information technology which 
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are both closely related to the discipline of systems engineering as well as highly relevant 
to the types of services commonly provided by SSC Atlantic. 

G. COMPETENCY DEVELOPMENT MODEL STAGES 

Competency models or frameworks typically come equipped with stages that 
define the levels of competence (or levels of KSAs) that an individual can develop in a 
given role. Most competency frameworks employ a three, four or five stage construct. 
For example, INCOSE uses the following four stage construct to define an individual’s 
level of expertise at various competency development levels: 

• Stage 1: Awareness —understands basic concepts; little to no experience 

• Stage 2: Supervised Practitioner —some real experience of the 
competency; application of techniques and concepts as part of his/her 
work 

• Stage 3: Practitioner —provides guidance and leads activities in this area; 
supervises and/or leads teams or groups of people 

• Stage 4: Expert —leads the field in a particular area; defines best- 
practices, policies or processes within an organization or industry 
(INCOSE, 2010) 

GRCSE uses the competency development levels or stages shown in Table 3. 


Level 1: Participate (Know) 

Performs fundamental and routine SE activities while supporting a Level ll-IV 
systems engineer as a member of a project team. 

Level II: Apply (Perform) 

Performs SE activities for a subsystem or simple project (e.g., no more than two 
simple internal/external interfaces, simpler contracting processes, smaller 
team/budget, and shorter duration). 

Level III: Manage (Lead) 

Performs as a systems engineer lead for a complex project (e.g., several distinct 
subsystems or other defined services, capabilities, or products and their 
associated Interfaces). 

Level IV: Guide (Strategize) 

Oversees SE activities for a program with several systems and/or establishes SE 
policies at the top organizational level. 


Table 3. GRCSE Competency Proficiency Levels (Erom GRCSE, 2012, p. 108) 


Other competency frameworks employ very similar competency development (or 
proficiency) levels where, generally speaking, the first level is knowing or understanding; 
the second level is executing SE; the third level involves leading teams in SE; and the 
fourth level involves defining best practices, policies and generally governing how SE is 
accomplished within an entire organization. Chapter III examines SSC Atlantic’s 
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implementation of a SE competency framework which utilizes a similar four-stage 
development concept. 

H. COMPETENCY VECTORS 

A competency vector (also known as a competency dimension), is a logical 
grouping of competency areas. Major competency vectors for a competency model vary 
from one framework to another. However, when compared side-by-side, the INCOSE, 
DAU SPRDE-SE/PSE and NASA SE competency frameworks display an interesting 
trend. All three frameworks address the SE technical processes, also known as the 
systems engineering “vee.” All three incorporate the SE technical management 
processes as well, encompassing such competency areas as risk management, 
requirements management and configuration management. All three incorporate various 
supporting techniques that span competency areas as system assurance, 
reliability/availability/maintainability (RAM), safety, and software engineering; however, 
these techniques are much more varied when compared between frameworks. All three 
frameworks also incorporate some form of competency vector associated with leadership 
skills or personal attributes. Two of the three (INCOSE and NASA) refer to some form 
of domain knowledge which provides the mission or context for why there is an 
operational need for the systems engineering being performed. The domain competency 
vector can encompass technology areas such as networks and sensors. The domain 
competency vector can also encompass engineering disciplines such as mechanical, 
electrical and structural engineering. Table 4 provides a side-by-side comparison of the 
three aforementioned SE competency frameworks and how they each address these five 
primary competency vectors. 
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Competency Model 

Competency Vector 

INCOSE (2010) 

DAU SPRDE-SE/PSE 
(2010) 

NASA (2009) 

Technical Processes 

Core Competencies 
(Sys Thinking, 

Holistic Lifecycle 
View) 

Analytical 

Competencies 

(Technical 

Processes) 

System Design & 

Product Realization 

Technical Mgt 

Processes 

Core Competencies 
(SE Mgt) 

Technical Mgt 
Competencies 

Technical 

Management 

Supporting 

Techniques 

Supporting 

Techniques 

Analytical 
Competencies 
(System Assurance, 
Software 

Engineering, Safety, 
RAM) 

Security, Safety & 

Mission Assurance 

Domain 

Domain Knowledge 

N/A 

Internal & External 

Environments 

Leadership/Personal 

Attributes 

Basic Skills and 

Behaviors 

Professional 

Competencies 

Professional & 

Leadership 

Development 


Note: NASA also has Human Capital Mgt & Knowledge Mgt as competency areas 
Table 4. Comparison of INCOSE, DAU and NASA SE Competency Vectors 


It should also be noted that the SEBoK states that there are typically four primary 
competency vectors (which they refer to as dimensions) to a SE competency model— 
disciplines, life cycle, domain and mission (Pyster et al., 2012, p. 709). The SEBoK cites 
aerospace and medical as two potential domain areas, for example (Pyster et al., 2012, 
p. 22). In the context of SSC Atlantic KSAs, the terms “domain” and “mission” can be 
used relatively interchangeably. Examples of domain or mission areas related to SSC 
Atlantic would include command and control, information operations and business 
operations. For the purposes of this paper, domain and mission are considered one in the 
same, as both provide context for the SE effort to be accomplished. 

1. DEPARTMENT OF NAVY SYSTEMS ENGINEERING COMPETENCY 
DEVELOPMENT MODEL 

As previously discussed, all three of the aforementioned SE competency 
frameworks provide tremendous value and are closely related to the SE practices 
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conducted at SSC Atlantic. So which framework should be chosen for tailoring at SSC 
Atlantic and the naval community at large? 

A Pragmatic Guide to Competency states: 

When it eomes to choosing between frameworks, then the seope of each 
and their intended audience becomes very important. This can lead to 
problems, however, as it is very rare that a single person will have their 
entire skillset chosen by a single frame work... One way to address this is 
to look for a eommon reference that ean be used as a starting point for 
mapping between the various competency frameworks. (Holt & Perry, 

2011, p. 30) 

Tasked by DASN RDT&E with bringing together and fusing the competency 
areas of the aforementioned SE eompetency frameworks in addition to those employed 
by Boeing and Naval Undersea Warfare Center (NUWC), the Naval Postgraduate School 
(NPS) has developed one common reference that can truly be used as the “north star” for 
Navy and U.S. Marine Corps SE organizations—the naval SE CDM. This thesis 
eontributed to the development of the Naval SE CDM, whieh foeuses on the competency 
vectors for SE technical processes, technical management processes and supporting 
techniques. The naval SE CDM deliberately leaves domain and leadership skill 
competency vectors outside of its scope for other, more appropriate competency 
reference models and frameworks to address and define. Figure 4 illustrates how five 
different eompetency models were fused into the naval SE CDM developed by the Naval 
Postgraduate Sehool. 
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Figure 4. Evolution of the Naval SE CDM Developed by NPS (From Alexander, 

2013, p. 29) 


The result of the NPS competency model synthesis was 25 different competency 
areas (also known as competencies) with over 2,000 KSAs identified for the naval SE 
CDM. For the purposes of developing a SE competency framework for SSC Atlantic, the 
naval SE CDM provides a wide array of KSAs from which to choose, along with 
recommended CDM stages (levels) for each individual knowledge, skill or ability. It 

should be noted that three of the competency areas originally identified in Version 3 of 
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the naval SE CDM were removed from the model as they were not specific to systems 
engineering; hence, the mention of 28 competency areas (or competencies) in Figure 4. 
The resulting 25 naval SE CDM competency areas are as such: 

• Technical basis for cost 

• Modeling & simulation 

• Safety assurance 

• Stakeholder requirements definition 

• Requirements analysis 

• Architecture design 

• Implementation 

• Integration 

• Verification 

• Validation 

• Transition 

• System assurance 

• Reliability, availability and maintainability (RAM) 

• Decision analysis 

• Technical planning 

• Technical assessment 

• Configuration management 

• Requirements management 

• Risk management 

• Technical data 

• Interface management 

• Software engineering 

• Acquisition 

• Systems of systems 

• Systems thinking 
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III. APPLYING SE COMPETENCY AREAS TO SSC ATLANTIC 


A. KNOWLEDGE, SKILLS AND ABILITIES FOR DIFFERENT USE CASES 

Chapter II introduced various SSC Atlantic use cases that leverage KSA data. In 
order to determine which competency vectors, competency areas and associated KSAs 
SSC Atlantic should adopt for its diverse set of systems engineers, one must gain a 
deeper appreciation for how the KSA data will be used. Three of these use cases— 
recruiting/hiring, individual competency development and training identification 
highlight the need for KSA data at three completely different levels of granularity (or 
abstraction). 


1. KSAs for Recruitment and Hiring of Systems Engineers 

In order to recruit and hire an employee at SSC Atlantic, a hiring package must be 
developed which includes position description information. This position description 
includes information such the individual’s pay grade, job series and clearance 
requirements. It also includes information regarding the individual’s duties and KSAs. 
For a typical hiring package, there are approximately five KSAs cited in the position 
description. Therefore, when recruiting and hiring a new systems engineer into the SSC 
Atlantic organization, only a limited set of KSAs will actually be specified. This requires 
the systems engineering KSAs to be used for the purpose of hiring and recruitment to be 
very broad. For example, if there are five competency vectors relevant to a systems 
engineer’s assigned duties, then the position description would only refer to about one 
KSA per competency vector. A shortened KSA for such a case might read something 
like, “knowledge of the systems engineering technical management processes” or “basic 
understanding of command and control as it applies to IT systems.” 

2. KSAs for Individual Competency Development 

Since 2008, SSC Atlantic competency development models (CDMs) for 
engineering divisions have typically consisted of approximately 10 to 15 KSAs per 
competency development stage. For example, a systems engineer currently certified at 
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the intermediate stage might be required to demonstrate proficiency in 12 different KSAs 
in order to progress to the level of advanced. Since there are four stages in an SSC 
Atlantic CDM, this equates to roughly 50 KSAs per CDM for any given role that 
individual might fulfill. In this case, we have approximately ten times as many KSAs 
defined for a systems engineer than we do in the use case associated with hiring and 
recruitment. For this level of detail, it would be insufficient to simply state that a systems 
engineer must have “knowledge of the systems engineering technical management 
processes.” Instead, a basic KSA for a systems engineer’s CDM might read something 
like, “ability to perform requirements management,” where requirements management is 
one of many technical management processes. 

3. KSAs for the Identification of Training Needs 

When individuals seek to develop specific KSAs for which they demonstrate little 
to no proficiency, they may seek to find available training opportunities. Oftentimes, the 
level of KSA granularity described in an SSC Atlantic CDM of approximately 50 KSAs 
is insufficient. For example, a systems engineer may need to develop a basic ability or 
skill in using requirements management tools. In the CDM for a systems engineer, one 
might find the KSA, “ability to perform Requirements Management for complex IT 
systems.” However, more detailed KSAs might not be identified for requirements 
management tools. For this reason, there is an additional need for an even larger quantity 
of KSAs to be specified for systems engineers that may add up to the hundreds or even 
thousands of KSAs. This allows a systems engineer to search for KSAs and associated 
training opportunities that can fulfill unique developmental needs. For SSC Atlantic, 
Total Workforce Management Services (TWMS) is the tool used to search for KSAs, find 
associated training opportunities and add these training events to individual development 
plans. Table 5 summarizes the three primary use cases for KSA usage and how they 
differ in terms of the typical quantity of KSAs they use. Figure 5 illustrates how a single 
KSA used for recruiting and hiring translates into usage in the other two use cases. 
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Use Case 

Source 

Typical # of 
KSAs 

Recruiting & 
Hiring 

Position description for the 
job of a systems engineer 

5 

Individual 

Competency 

Development 

CDM for a systems engineer 

50 

Training Needs 
Identification 

Total Workforce 
Management Services 
(TWMS) KSA & Training 
Database 

500 


Table 5. SSC Atlantic KSA Use Cases and Typical KSA Quantities 


How a single KSA associated with Recruiting and Hiring 
translates to other use cases 


Recruiting & Hiring 


Ability to apply 
Technical Management 
Processes in the 
engi n eeri ng of co m p I ex 
IT systems 


=> 


Individual 

Competency 

Development 


Ability to perform 
Requirements 
Management for 
complex IT systems 


Ability to perform 
Configuration 
Management for 
complex IT systems 


Ability to perform 
Risk Management for 
complex IT systems 


+ 7 more 


=> 


Training 

Identification 


Ability to maintain 
requirements 
traceability by using a 
requirements 
traceability matrix 

Ability to manipulate 
requirements 
management tools in 
the execution of 
requirements 
management 


Ability to develop a 
requirements 
management plan 

Ability to identify 
technical risks 

Knowledge of risk 
mitigation strategies 
+ 45 more 


Figure 5. How a KSA Associated with One Use Case Translates to Other Use 

Cases 
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B. APPLYING BLOOM’S TAXONOMY TO CLARIFY DESIRED 
KNOWLEDGE, SKILLS AND ABILITIES 

KSAs can be stated at any level of granularity to fit the need of their use and are 
stratified across various competency development or proficiency stages, such as entry, 
intermediate, advaneed and expert. KSAs can also be classified by Bloom’s taxonomy 
into three different domains and categories. Dr. Benjamin Bloom created Bloom’s 
taxonomy in 1956 in order to encourage the developing of KSAs in ways other than just 
memorization of facts. This led to the definition of three learning domains—cognitive, 
affective and psychomotor (Bloom, 1956). The cognitive domain involves knowledge 
and the development of intelleetual skills (Bloom, 1956). GRCSE focuses more heavily 
on the cognitive domain than the other two domains. The psychomotor domain is 
arguably the least relevant to SE KSAs, as it focuses primarily on physical skills. 
However, the affeetive domain, which focuses on dealing with emotions, can also play a 
key role in the development of systems engineers in the systems thinking eompeteney 
area. The GRCSE highlights the importance of systems engineers developing KSAs in 
the affective domain: 

A key role of the systems engineer is to lead the development of systems. 

This role includes working with engineered systems, deliberately taking a 
systems perspective, and negotiating solutions with multiple, diverse 
stakeholders. These requirements of a systems engineer make their 
proficiency in the attributes of the affective domain critical to their 
suecess. (GRCSE, 2012, p. 86) 

The cognitive and affective domains of Bloom’s taxonomy are each subdivided 
by eategories as shown in Figure 6. 
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Figure 6. Bloom’s Taxonomy in the Cognitive and Affective Domains and the 
Hierarchy of Achievement (From GRCSE, 2012, p. 86) 


A key feature of the naval SE CDM is that it tags each of its KSAs with the 
Bloom’s domain and category levels that are most applicable. The GRCSE asserts that, 
within Bloom’s categories or levels, as shown in Eigure 6: 

...progression from one level to another is not only the result of more 
study, but also results from the direction of the study effort to develop a 
different kind of capability. For example, progression from ‘Knowledge’ 
to ‘Comprehension’ is not attained by the same type of studying that 
achieved the original knowledge... Similarly, ‘Analysis’ and ‘Synthesis’ 
are different kinds of skills that involve different approaches to thinking 
about the subject matter... synthesis is not simply more analysis, but 
rather a different kind of activity based on a different kind of learning. 
(GRCSE, 2012, p. 87) 

Certain key verbs can help in classifying a knowledge, skill or ability into a 
Bloom’s domain and category/level. For example, the ability to apply (the “application” 
category of the cognitive domain) might use verbs such as demonstrate, employ, illustrate 
or produce. Tables 6 and 7 from highlight examples and the key verbs that are 
commonly associated with each of Bloom’s cognitive and affective domain levels. 
Categorizing KSAs in this manner will prove useful in Chapter V, which looks at the 
optimal ways of developing KSAs. 
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Category 

Example and Key Verbs 

Remembering (Knowledge): Recall 
previous learned information. 

Examples: Recite a policy. Quote prices from memory to a 
customer. Knows the safety rules. 

Key Words: defines, describes, identifies, knows, labels, lists, 
matches, names, outlines, recalls, recognizes, reproduces, 
selects, states. 

Understanding (Comprehension): 

Comprehending the meaning, 
translation, interpolation, and 
interpretation of instructions and 
problems. State a problem in one's 
own words. 

Examples: Rewrites the principles of test writing. Explain in 
one's own words the steps for performing a complex task. 
Translates an equation into a computer spreadsheet. 

Key Words: comprehends, converts, defends, distinguishes, 
estimates, explains, extends, generalizes, gives an example, 
infers, interprets, paraphrases, predicts, rewrites, summarizes, 
translates. 

Applying (Application): Use a 

concept in a new situation or 
unprompted use of an abstraction. 
Applies what was learned in the 
classroom into novel situations in the 
work place. 

Examples: Use a manual to calculate an employee's vacation 
time. Apply laws of statistics to evaluate the reliability of a 
written test. 

Key Words: applies, changes, computes, constructs, 
demonstrates, discovers, manipulates, modifies, operates, 
predicts, prepares, produces, relates, shows, solves, uses. 

Analyzing (Analysis): Separates 
material or concepts into component 
parts so that its organizational 
structure may be understood. 
Distinguishes between facts and 
inferences. 

Examples: Troubleshoot a piece of equipment by using logical 
deduction. Recognize logical fallacies in reasoning. Gathers 
information from a department and selects the required tasks for 
training. 

Key Words: analyzes, breaks down, compares, 
contrasts, diagrams, deconstructs, differentiates, discriminates, 
distinguishes, identifies, illustrates, infers, outlines, relates, 
selects, separates. 

Evaluating (Evaluation): Make 
judgments about the value of ideas or 
materials. 

Examples: Select the most effective solution. Hire the most 
qualified candidate. Explain and justify a new budget. 

Key Words: appraises, compares, concludes, contrasts, 
criticizes, critiques, defends, describes, discriminates, evaluates, 
explains, interprets, justifies, relates, summarizes, supports. 

Creating (Synthesis): Builds a 
structure or pattern from diverse 
elements. Put parts together to form 
a whole, with emphasis on creating a 
new meaning or structure. 

Examples: Write a company operations or process manual. 

Design a machine to perform a specific task. Integrates training 
from several sources to solve a problem. Revises and process to 
improve the outcome. 

Key Words: categorizes, combines, compiles, composes, 
creates, devises, designs, explains, generates, modifies, 
organizes, plans, rearranges, reconstructs, relates, reorganizes, 
revises, rewrites, summarizes, tells, writes. 


Table 6. Categories of Bloom’s Cognitive Domain (After Bloom’s Taxonomy of 

Learning Domains, 2013) 
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Category 

Example and Key Verbs 

Examples: Listen to others with respect. Listen for 
and remember the name of newly introduced 

Receiving Phenomena: Awareness, willingness 
to hear, selected attention. 

people. 

Key Words: asks, chooses, describes, follows, 
gives, holds, identifies, locates, names, points to, 
selects, sits, erects, replies, uses. 

Responding to Phenomena: Active participation 
on the part of the learners. Attends and reacts to a 
particular phenomenon. Learning outcomes may 
emphasize compliance in responding, willingness 
to respond, or satisfaction in responding 
(motivation). 

Examples: Participates in class discussions. Gives 
a presentation. Questions new ideals, concepts, 
models, etc. in order to fully understand them. 

Know the safety rules and practices them. 

Key Words: answers, assists, aids, complies, 
conforms, discusses, greets, helps, labels, performs, 
practices, presents, reads, recites, reports, selects, 
tells, writes. 

Valuing: The worth or value a person attaches to 
a particular object, phenomenon, or 
behavior. This ranges from simple acceptance to 
the more complex state of commitment. Valuing 
is based on the internalization of a set of specified 
values, while clues to these values are expressed 
in the learner's overt behavior and are often 
identifiable. 

Examples: Demonstrates belief in the democratic 
process. Is sensitive towards individual and cultural 
differences (value diversity). Shows the ability to 
solve problems. Proposes a plan to social 
improvement and follows through with 
commitment. Informs management on matters that 
one feels strongly about. 

Key Words: completes, demonstrates, 
differentiates, explains, follows, forms, initiates, 
invites, joins, justifies, proposes, reads, reports, 
selects, shares, studies, works. 

Organization: Organizes values into priorities by 
contrasting different values, resolving conflicts 
between them, and creating an unique value 
system. The emphasis is on comparing, relating, 
and synthesizing values. 

Examples: Recognizes the need for balance 
between freedom and responsible behavior. Accepts 
responsibility for one's behavior. Explains the role 
of systematic planning in solving problems. Accepts 
professional ethical standards. Creates a life plan in 
harmony with abilities, interests, and beliefs. 
Prioritizes time effectively to meet the needs of the 
organization, family, and self. 

Key Words: adheres, alters, arranges, combines, 
compares, completes, defends, explains, formulates, 
generalizes, identifies, integrates, modifies, orders, 
organizes, prepares, relates, synthesizes. 

Internalizing values (Characterization): Has a 

value system that controls their behavior. The 
behavior is pervasive, consistent, predictable, and 
most importantly, characteristic of the 
learner. Instructional objectives are concerned 
with the student's general patterns of adjustment 
(personal, social, emotional). 

Examples: Shows self-reliance when working 
independently. Cooperates in group 
activities (displays teamwork). Uses an objective 
approach in problem solving. Displays a 
professional commitment to ethical practice on a 
daily basis. Revises judgments and changes 
behavior in light of new evidence. Values people 
for what they are, not how they look. 

Key Words: acts, discriminates, displays, 
influences, listens, modifies, performs, practices, 
proposes, qualifies, questions, revises, serves, 
solves, verifies. 


Table 7. Categories of Bloom’s Affective Domain (After Bloom’s Taxonomy of 

Learning Domains, 2013) 
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C. SSC ATLANTIC ENGINEERING PROCESS FRAMEWORK 

There are a number of different life cycle models that serve as a guide for 
conducting engineering and acquisition processes. The Project Management Body of 
Knowledge (PMBoK) provides a framework for projects of varying sizes and degrees, 
spanning project initiation, planning, execution, monitoring/control and closeout. For the 
Department of Defense, the defense acquisition management framework provides an 
event-based process in which “acquisition programs proceed through a series of 
milestone reviews and other decision points that may authorize entry into a significant 
new program phase” (Defense Acquisition University, 2011). 

The systems engineering “Vee” is commonly used to describe the systems 
engineering processes associated with requirements development, design, 
implementation, integration, verification, validation operations and sustainment. The 
SPAWAR Systems Engineering Guidebook (SSEG), which is used by SPAWAR 
Headquarters, SSC Atlantic and SSC Pacific, adopts a similar model as shown in Figure 
7, which depicts the original SSEG process framework. Here the technical management 
processes are shown across the top to represent that they are conducted throughout the 
project and systems engineering life cycle. The classical SE “Vee” is shown in the center 
of the diagram through the solution design and production realization processes. As of 
July 2013, the SSEG remains in beta form and continues to be revised by the SPAWAR 
engineering department. Figure 8 depicts the updated SSEG process framework, which 
has abandoned the SE “Vee” visual. 
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Figure 7. Original SSEG Process Framework 
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Figure 8. SSEG Process Framework as of July 2013 

In May 2013, SSC Atlantic established Version 1.0 of the SSC Atlantic Systems 
Engineering Framework that organizes its SE process areas at the highest level by the 
SSC Project Lifecycle, also known as the PLC. Figure 9 shows how the PLC combines 
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basic elements of the PMBoK project management life cycle such as project initiation, 
planning and closeout with systems engineering process areas such as requirements 
development, design, integration, testing, operations and sustainment. Hence, the PLC 
represents the complementary nature within SPAWAR of the role of the program or 
project manager with that of the systems engineer. The SSC Atlantic Systems 
Engineering Framework Version 1.0, depicted in Figure 10, shows how the PLC is 
supported by engineering guidanee set forth in the Naval Systems Engineering Guide, 
SSEG, Defense Acquisition Guidebook and other organizational standard proeesses as 
well as by the technical management and technical/engineering processes commonly 
found in SE life cycle models. 



Figure 9. Project Life Cyele 
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Figure 10. SSC Atlantic SE Process Framework vl.O 


While at the first level, the SSC Atlantic SE Framework leverages the PLC as a 
general lifecycle guide, at the second level, the Engineering Processes align with the 
competency areas as defined in the Naval SE CDM. Eor example, requirements 
management, interface management and risk management are depicted as technical 
management processes, while stakeholder requirements definition and requirements 
analysis show up as engineering processes, which are very closely aligned to DAU 
technical processes. The SSC Atlantic SE Framework serves as a guide for systems 
engineers to discover related standard operating procedures, tools, templates, checklists 
and other aids that can assist them with executing SE processes and developing related 
KSAs. The latest version of the SSC Atlantic SE Process Framework is scheduled to be 
published to the SSC Atlantic Command Operating Guide by the end of calendar year 
2013. 

D. COMPETENCY VECTORS RELEVANT TO SE AT SSC ATLANTIC 

While the systems engineering life cycle process framework plays a major role in 

framing and defining the KSAs of systems engineers at SSC Atlantic, it is not the only 

dimension or competency vector. It is also important for systems engineers to understand 

why they are engineering and supporting the solutions they are delivering. For that 

reason, a critical competency vector for SSC Atlantic systems engineers must be 

associated with the domain or mission that the engineered solutions ultimately support. 

For example, a naval command and control (C2) or information operations (lO) mission 
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may require IT systems that transmit certain types of information, improve critical 
mission times or provide more robust warfighting capabilities. Such mission or 
capability areas can be framed in a variety of different ways. For example, the Joint 
Capability Areas (JCAs) can be used to provide a high level framework for the capability 
areas associated with Joint services. In order for a systems engineer to effectively fulfill 
any such capability gaps, he or she must truly understand the real problem at hand in a 
holistic manner. 

SSC Atlantic’s vision statement is to “Make IT Count for the Warfighter and the 
Nation.” IT is defined as “the application of computers and telecommunications 
equipment to store, retrieve, transmit and manipulate data” (Daintith, 2009). By taking a 
closer look at the definition of IT, a major competency vector can be established for the 
development of IT-savvy systems engineers. The application portion of this definition 
refers to the SE process areas as the root term “apply” means “to put to use,” which 
makes sense as SE is a “means to enable the realization of successful systems” (INCOSE, 
2004, p. 12). The other major component of IT is the technology itself—computers and 
telecommunications equipment. Within SSC Atlantic, the major technology areas most 
commonly associated with IT are networks, radio frequency (RE) communications, 
computer applications and sensors. In fact, several hundred systems engineers at SSC 
Atlantic are aligned to networks, communications or computer applications as their 
primary competency area. This naturally leads to a third competency vector, which will 
be referred to as “technology.” Figure 11 depicts the three primary competency vectors 
for SSC Atlantic systems engineers—mission, technology and activities (SE life cycle 
processes). 
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The fourth and final competency vector critical to the development of systems 
engineers at SSC Atlantic is one that is core to practically any employee in any 
workplace environment —leadership skills. Figure 12 depicts the four-vector competency 
framework of mission, technology, activities and leadership skills. Leadership skills 
typically encompass skills or attributes such as those related to oral and written 
communications, conflict management, team building, strategic thinking, customer 
service and integrity. Appendix B provides a complete breakdown of the leadership 
skills (otherwise known as personal attributes), definitions/indicators and recommended 
competency development stage/level. These leadership skills are summarized below: 

• Accountability 

• Communication (oral and written) 

• Conflict management 

• Continual learning 

• Creativity / innovation 

• Customer service 

• Decisiveness / problem solving 
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• Entrepreneurship 

• External awareness / political savvy 

• Financial management 

• Flexibility / resilience 

• Human capital management 

• Information management 

• Integrity / honesty 

• Interpersonal skills 

• Leadership / influence / negotiation 

• Partnering / collaborative performance 

• Self-management 

• Service motivation 

• Strategic thinking / vision 

• Team building 

• Technical expertise 

• Technology credibility 

• Technology management 
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Figure 12. SSC Atlantic Four-vector SE Competency Framework 


E. PRIORITIZATION OF SE COMPETENCY AREAS 

In his brief entitled, “A Framework to Institutionalize Systems Engineering Skill- 
Set” Ebad Jahangir examines the SE competency frameworks from NASA and INCOSE 
and makes the recommendation that there are five primary “critical skills” (most closely 
related to competency vectors)—systems thinking, systems architecture, technical 
management, product realization and leadership skills (2012). Table 8 depicts Jahangir’s 
five critical skills and associated enabling skills (much like competency areas). Systems 
thinking, as defined by INCOSE, maps effectively to the systems thinking competency 
area defined by the naval SE CDM, as well as the mission/capability focus as addressed 
by the mission competency vector. INCOSE’s system architecture, technical 
management and product realization are directly traceable to the SE lifecycle (activity) 
competency areas. The leadership skills map directly to the leadership skills or personal 
attributes competency vector. 
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Critical Skill 

■ 

Enabling Skills 

Systems Thinking 

System Architecture 

Business and technology environment 

Super-system capability issues 

Systems concepts 

Stakeholder Expectation Definition 

Technical Requirements Definition 

Logical Decomposition 

Design Solution Definition 

Technical Management 

Technical Planning 

Requirements Management 

Interface Management 

Technical Risk Management 

Configuration Management 

Technical Data Management 

Technical Assessment 

Technical Decision Analysis 

Product Realization 

Product Implementation 

Product Integration 

Product Verification 

Product Validation 

Product Transition 

Leadership Skills 

Coaching 

Communication: Verbal, non-verbal and listening 
Communication: Technical report writing 

Knowing when to ask 

Lateral thinking 

Negotiation and influencing 

Team working 


Table 8. Jahangir’s Five Critical Skills (Competency Vectors) for Systems Engineers 

(From Jahangir, 2012) 


While Jahangir’s model (as well as those of INCOSE, DAU and NASA) may not 
reflect the IT focus of SSC Atlantic, the national cybersecurity workforce framework 
(NCWF) developed by NIST does. According to NIST, “The National Cybersecurity 
Workforce Framework establishes the common taxonomy and lexicon that is to be used 
to describe all cybersecurity work and workers irrespective of where or for whom the 
work is performed’’ (NIST, 2011, p. 7). The NCWE defines typical cybersecurity 
workforce tasks and KSAs needed in the areas of network services, telecommunications, 
and computer applications in sufficient detail to support the hiring/recruiting and 
individual competency development SSC Atlantic use cases. 
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Chapter V, Section E discusses five common SE use cases that may be 
encountered by an SSC Atlantic IPX. Each of these SE use cases emphasizes the 
importance of different competency areas and competency vectors. Table 9 depicts 
which competency areas and vectors are emphasized in each use case by placing an “X” 
in the appropriate cell. The Total SE Use Case Score is determined by adding up the 
number of use cases which stress the respective competency area or vector. Table 9 also 
depicts the result of an analysis conducted by Gelosh in What Defines a Systems 
Engineer? Comparing and Contrasting Global Perspectives on Systems-Engineering 
Competency. Gelosh’s analysis compared the relative importance or emphasis of a 
particular SE competency area to the DoD versus industry (understood as settings outside 
of the DoD). The far right column of Table 9 takes the average score of the Total SE Use 
Case Score, Gelosh’s DoD Score and Gelosh’s Industry Score to provide a final score for 
each competency area and vector. In summary, this average or final score shown on the 
far right of Table 9 considers various SSC Atlantic SE use cases, the DoD’s emphasis and 
the emphasis of Industry at large to prioritize the relative importance for each of the 
competency areas and vectors to be used by SSC Atlantic. Competency areas and vectors 
with final scores above 3.5 are considered to be most important. Competency areas and 
vectors with final scores of 3.0 to 3.5 are considered moderately important, while those 
with scores under 3.0 are considered mildly important. It should be noted that sensitivity 
analysis with weighting of the SSC Atlantic use cases and Gelosh’s scores with respect to 
each other shift the rankings to a certain degree, but not significantly. 
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SE Use Cases (X = competency area or vector em 

phasized) 


G< 

Com 

dosh 

jarison 


Avg of SE Use 
Case, DoD & 
Industry 
Scores 

Competency Area (or Vector) 

Component 

Engineering 

Simple 

SE 

Complex 

SE 

Platform 

SE 

SoSE 

Total SE Use 
Case Score 

DoD 

Score 

Industry 

Score 

Stakeholder Requirements 
Definition 

X 

X 

X 

X 

X 

5 

4 

4 

4.33 

Requirements Analysis 

X 

X 

X 

X 

X 

5 

3 

4 

4.00 

Architecture Design 

X 

X 

X 

X 

X 

5 

3 

4 

4.00 

Software Engineering 


X 

X 

X 

X 

4 

4 

4 

4.00 

Acquisition 

X 

X 

X 

X 

X 

5 

3 

4 

4.00 

Technology Competency Vector 

X 

X 

X 

X 


4 

N/A 

N/A 

4.00 

Technical Basis for Cost 

X 

X 

X 

X 

X 

5 

3 

3 

3.67 

Verification 

X 

X 


X 


3 

4 

4 

3.67 

System Assurance 


X 

X 

X 

X 

4 

4 

3 

3.67 

Decision Analysis 

X 

X 

X 



3 

4 

3 

3.33 

Technical Planning 


X 

X 

X 

X 

4 

4 

2 

3.33 

Configuration Management 


X 

X 

X 

X 

4 

3 

3 

3.33 

Requirements Management 



X 

X 

X 

3 


4 

3 


3.33 

Risk Management 



X 

X 

X 

3 


4 

3 


3.33 

Technical Data Management 


X 

X 

X 

X 

4 

3 

3 

3.33 

Interface Management 



X 

X 

X 

3 


4 

3 


3.33 

Implementation 

X 

X 

X 

X 


4 

2 

3 

3.00 

Integration 



X 

X 

X 

3 

3 

3 

3.00 

Validation 



X 

X 

X 

3 


4 

2 


3.00 

Transition 


X 

X 

X 


3 

2 

4 

3.00 

Systems Thinking 



X 

X 

X 

3 


N/A 

N/A 


3.00 

Mission Competency Vector 



X 

X 

X 

3 

N/A 

N/A 

3.00 

Modeling & Simulation 



X 

X 

X 

3 


2 

3 


2.67 

Reliability, Ayailability & 
Maintainability 

X 

X 




2 

2 

4 


2.67 

Technical Assessment 



X 

X 

X 

3 

4 

1 

2.67 

Safety Assurance 




X 


1 

4 

2 

2.33 

Systems of Systems 



X 

X 

X 

3 

1 

1 

1.67 


Table 9. Ranking the Emphasis of Competency Areas and Vectors against Various SE Use Cases. Gelosh Comparison Addresses 

DoD versus Industry Perspective (After Gelosh, 2009) 
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Of the most important competency areas and vectors, the stakeholder 
requirements definition, requirements analysis and architecture design competency areas 
all represent processes near the beginning of the SE life cycle. The importance of these 
process areas underscores the need to get the requirements and architecture “right,” lest 
the total cost of ownership for the system increase significantly over the course of the life 
of the system. Other noteworthy process areas that scored high include software 
engineering and system assurance—two competency areas that have continued to 
increase in importance over the last several years due to systems’ reliance on software 
and the need for cybersecurity. 

Even though some processes were rated as mildly important, that is not to say that 
they are not critical. One challenge with the systems of systems competency area is that 
this use case only represents a small percentage of total projects; therefore, it is not 
currently emphasized a great deal. It is also difficult to train systems engineers in 
systems of systems engineering (SoSE) as the methodologies associated with SoSE are 
still relatively immature. Systems thinking is another competency area that is arguably 
very critical to SE, yet it is not very prescriptive, and thus does not translate effectively to 
a well-defined process that can be monitored and controlled. Safety assurance also fell 
into the lower-scoring category primarily due to the fact that it is simply a discipline that 
is not as critical in the IT domain as in those of a more physical realm. 
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IV. DESIGNING A NEW COMPETENCY ERAMEWORK FOR 
SSC ATLANTIC SE ROLES AND SUBROLES 

A. SSC ATLANTIC SE COMPETENCY ERAMEWORK 

Chapter II provided an analysis of the anatomy of a competency framework in 
terms of competency vectors, competency areas and associated KSAs. Chapter II also 
highlighted the critical competency vectors and competency areas associated with 
performing systems engineering at SSC Atlantic. By defining the critical competency 
vectors of SSC Atlantic systems engineering to be missions, activities and technologies, 
the SSC Atlantic systems engineering competency framework depicted in Figure 13 is 
established. The competency vector associated with leadership skills is not explicitly 
depicted in the framework since it applies more broadly to the entire SSC Atlantic (or 
practically any) workforce—not just to systems engineers. Within each of the 
competency vectors, there are several competency areas under which KSAs are defined. 
These KSAs originate from each of the sources defined in the previous chapters (namely 
the naval SE CDM, INCOSE, DAU, NASA and NIST) as well as from existing SSC 
Atlantic engineering CDMs. Each individual KSA is assigned an associated competency 
development stage—entry, intermediate, advanced or expert. 
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Figure 13. SSC Atlantic Systems Engineering Competency Framework 


In order to define the associated competency development model (CDM) for any 
variant (or specialty, subrole) of a systems engineer role, one can simply choose which 
sets of KSAs most apply. In doing so, care must be taken not to choose too many KSAs 
so as not to make the process of assessing an individual against a CDM too time- 
consuming. The need to control the number of total KSAs for a given role’s CDM was 
discussed in earlier in Chapter III—KSA Use Case 2. Figure 14 depicts a high level view 
of how KSAs in different competency areas may be mapped or assigned to a systems 
engineer’s CDM. 
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Figure 14. KSAs from Different Competency Areas Assigned to Systems Engineer 

CDM 


B. SSC ATLANTIC ENGINEERING DEPARTMENT CORE KSAS 


Before a determination can be made as to which KSAs should be common to all 


systems engineers, one must first determine which KSAs are common (or core) to all of 
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the SSC Atlantic Engineering Department. KSAs chosen as part of the “core” 
Engineering CDM would be included in every engineering department employee’s CDM. 
In April 2013, key members of the SSC Atlantic Engineering Department leadership 
reviewed over 4,000 KSAs to determine those that were core to all 2,000+ members of 
the engineering department at the entry and intermediate CDM stages. KSAs at the 
advanced and expert stages would be assumed to be only role-specific, where the role of 
a systems engineer is just one of many engineering department roles. A total of 11 
representatives participated in the identification of these core KSAs across the following 
engineering divisions and departments: Net-centric Engineering and Integration; 
Computer Applications; Network and Communications; Intelligence, Surveillance, 
Reconnaissance (ISR) / Information Operations (10); Space; Information Assurance; and 
Test, Evaluation & Certification. For each of the KSAs that could potentially be 
considered core to all of the SSC Atlantic Engineering Department’s overarching CDM, 
10 of the 11 possible votes had to be affirmative. Of the 4,000+ KSAs identified as 
potential candidates, 62 were ultimately selected as common to all of the SSC Atlantic 
Engineering Department. Table 10 identifies these core engineering KSAs, their 
respective competency area and associated competency development stage. 
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Competency 

Vector 

Competency Area 

KSA 

Stage 

Activity 

GENERAL 

Basic knowledge of technical and 
technical mgt processes 

Entry 

Activity 

GENERAL 

Knowledge of engineering/technical 
artifacts required by SSC Atlantic 

Entry 

Activity 

GENERAL 

Ability to review engineering/technical 
artifacts for completeness and quality 

Intermediate 

Activity 

1.0 TECHNICAL BA 

SIS FOR COST 

Knowledge of SPA WAR accounting and 
financial systems 

Entry 

Activity 

1.0 TECHNICAL BA 

SIS FOR COST 

Ability to contribute to timely and 
accurate full cost budget information 
(such as labor, procurement, travel 
estimates) to project managers when 
requested 

Entry 

Activity 

1.0 TECHNICAL BA 

SIS FOR COST 

Ability to perform cost estimating on 
technical work products 

Entry 

Activity 

1.0 TECHNICAL BA 

SIS FOR COST 

Ability to use Work Breakdown 

Structure (WBS) as a tool for tracking 
actual vs. estimated costs and use this 

information to revise cost models 
appropriately 

Entry 

Activity 

2.0 MODELING & 

SIMULATION 

Knowledge of decision support tools, 
models, or simulations that are 
applicable to your job. 

Entry 

Activity 

3.0 SAFETY 

ASSURANCE 

Understand and comply with safety 
strategies, policies, and standards 

Entry 

Activity 

3.0 SAFETY 

ASSURANCE 

Understands the relationship between 
reliability, availability, maintainability 
and safety 

Intermediate 

Activity 

4.0 STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Able to identify major stakeholders 

Entry 

Activity 

4.0 STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Understand the importance of 
requirements traceability 

Entry 

Activity 

4.0 STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Can support the elicitation of 
requirements from stakeholders 

Intermediate 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Understands that there are different 
types of requirements e.g. functional, 
non-functional, business etc. 

Entry 
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Competency 

Vector 

Competency Area 

KSA 

Stage 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Understands the importance of 
managing requirements throughout the 
lifecycle 

Entry 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Understands the need for good quality 
requirements (achievable, verifiable, 
unambiguous, necessary and sufficient, 
complete, expressed as a need, 
consistent, and appropriate) 

Entry 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Contribute to decomposition of 
requirements 

Entry 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Contribute to development of 
specification documents 

Entry 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Understands the relationship between 
design and requirements 

Intermediate 

Activity 

5.0 

REQUIREMENTS 

ANALYSIS 

Ability to identify and analyze 
requirements 

Intermediate 

Activity 

6.0 ARCHITECTUR 

E DESIGN 

Basic knowledge of the different types 
of architecture 

Entry 

Activity 

6.0 ARCHITECTUR 

E DESIGN 

Identifies systems interfaces and 
interoperability concerns. 

Entry 

Activity 

6.0 ARCHITECTUR 

E DESIGN 

Understands the need to explore 
alternative and innovative ways of 
satisfying the system need 

Entry 

Activity 

6.0 ARCHITECTUR 

E DESIGN 

Knowledge of the principles of 
architectural design and its role within 
the lifecycle 

Entry 

Activity 

6.0 ARCHITECTUR 

E DESIGN 

Identify the basic elements/sections of 
an Technical Data Package (TDP) 

Entry 

Activity 

10.0 VALIDATION 

Understands the purpose of validation 

Entry 

Activity 

10.0 VALIDATION 

Understand structure and basic 

elements of a SOVT document 

Entry 

Activity 

11.0 TRANSITION 

Aware of the type of activities required 
for transition to operation 

Entry 

Activity 

12.0 SYSTEM ASSU 

RANCE 

Knowledge of Risk Management 
Framework (RMF) 

Entry 
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Competency 

Vector 

Competency Area 

KSA 

stage 

Activity 

12.0 SYSTEM ASSU 

RANGE 

Knowledge of information assurance 
principles and tenets (confidentiality, 
integrity, availability, authentication, 
non-repudiation). 

Entry 

Activity 

15.0 TECHNICAL P 

LANNING 

Basic knowledge of technical 
disciplines/specialties applicable to 
command 

Entry 

Activity 

15.0 TECHNICAL P 

LANNING 

Knowledge of the command's global 

WBS 

Intermediate 

Activity 

15.0 TECHNICAL P 

LANNING 

Able to tailor systems engineering 
processes to meet the needs of a 
specific project/program 

Intermediate 

Activity 

15.0 TECHNICAL P 

LANNING 

Understands the importance of 
planning, monitoring and controlling 
systems engineering activities 

Entry 

Activity 

15.0 TECHNICAL P 

LANNING 

Aware that common technical processes 
need to be planned 

Entry 

Activity 

16.0 TECHNICAL A 

SSESSMENT 

Able to (for a subsystem or simple 
project) monitor progress against plans 

Intermediate 

Activity 

16.0 TECHNICAL A 

SSESSMENT 

Identifies continuous process 
improvements that enhance processes, 
products, and service quality. 

Entry 

Activity 

16.0 TECHNICAL A 

SSESSMENT 

Aware of review types and their 
purposes 

Entry 

Activity 

16.0 TECHNICAL A 

SSESSMENT 

Aware of activities to prepare for 
technical assessments 

Entry 

Activity 

17.0CONFIGURAT 

ION MANAGEMEN 

T 

Knowledge and basic abilities associated 
to perform configuration management 
activities 

Entry 

Activity 

17.0CONFIGURAT 

ION MANAGEMEN 

T 

Aware of configuration change control 

Entry 

Activity 

18.0 REQUIREMEN 
TS MANAGEMENT 

Participate in (for a subsystem or simple 
project) documenting requirements in 
the proper 
format. 

Intermediate 

Activity 

18.0 REQUIREMEN 
TS MANAGEMENT 

Knowledge of the Engineering Change 
Proposal (ECP) review process 

Entry 

Activity 

18.0 REQUIREMEN 
TS MANAGEMENT 

Knowledge of requirements 
management process. 

Entry 
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Competency 

Vector 

Competency Area 

KSA 

Stage 

Activity 

19.0 RISK MANAG 

EMENT 

Knowledge of and the ability to 
contribute to identification of risk, risk 
analysis, and risk monitoring 

Entry 

Activity 

19.0 RISK MANAG 

EMENT 

Assists in executing the risk mitigation 
plan to ensure successful project and 
program completion. 

Entry 

Activity 

20.0 TECHNICAL 

DATA 

Ability to document and present lessons 
learned 

Entry 

Activity 

21.0 INTERFACE M 

ANAGEMENT 

Understands the need for interface 
management and its impact on the 
integrity of the system solution 

Entry 

Activity 

22.0 SOFTWARE 

ENGINEERING 

Basic understanding of software 
engineering principles 

Entry 

Activity 

23.0 ACQUISITION 

Ability to develop a Performance Work 
Statement (PWS) / Statement of 
Objectives (SOO) 

Intermediate 

Activity 

23.0 ACQUISITION 

Provides information for the 

Performance Work Statement (PWS) / 
Statement of Objectives (SOO) 

Entry 

Activity 

25.0 SYSTEM OF S 

YSTEMS 

Understands that SoS capability needs 
impact the system development 

Entry 

Activity 

30.0 SYSTEMS 

THINKING 

Able to describe the systems 
engineering lifecycle processes that are 
in place on their program 

Intermediate 

Activity 

30.0 SYSTEMS 

THINKING 

Able to define system boundaries and 
external interfaces 

Intermediate 

Activity 

30.0 SYSTEMS 

THINKING 

Aware of the influence the system has 
on the enterprise 

Entry 

Activity 

Data Engineering 

Aware of data management and data 
storage concepts 

Entry 

Activity 

Enterprise 

Architecture 

Understand the purpose and value of 
using architectures for requirements 
documentation, systems planning and 
investment decisions 

Entry 

Activity 

Enterprise 

Architecture 

Knowledge of DoD enterprise 
architecture principles and reference 
models 

Intermediate 

Technology 

Communications 

Basic knowledge of the characteristics of 
different communications systems 

Entry 
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Competency 

Vector 

Competency Area 

KSA 

stage 

Technology 

IT SERVICE 

MANAGEMENT 

Awareness DoD and DON ITSM policies, 
guidance and core references 

Entry 

Technology 

Networks 

Knowledge of computer networking 
fundamentals 

Entry 

Mission 

GENERAL 

Basic understanding of all Mission Areas 
/ Domains 

Entry 


Table 10. KSAs core to all members of SSC Atlantic Engineering Department 


C. SSC ATLANTIC ENGINEERING ROLES 

With common KSAs established for all members of the SSC Atlantic Engineering 
Department, attention can now be focused towards identifying the roles and subroles that 
can be performed by employees of the department. The role of a systems engineer is one 
of many roles that can be performed at SSC Atlantic. As of June 2013, SSC Atlantic had 
identified the following roles to be germane to the SSC Atlantic Engineering Department: 

• Systems engineer 

• Technical specialist 

• Software professional 

• Data professional 

• IT service management specialist 

• Tester 

• Information assurance (lA) professional 

• Mission specialist 

• Architect (a.k.a. enterprise architect) 

Each of the KSAs that are identified for a systems engineer may also be used for 
other roles as well. In other words, some KSAs may be unique to a particular role, 
whereas some KSAs may be common to multiple roles. Chapter IV, Section B 
highlighted an extreme case where certain KSAs were considered to be common to all 
roles and, therefore, core to all members of the SSC Atlantic Engineering Department. 
Figure 15 shows how the role of a tester may share some of the basic KSA requirements 
as that of a systems engineer; however, the tester role also stresses KSAs in the 
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competency area of validation that the basic systems engineer CDM would not include. 
Conversely, a systems engineer is expected to develop a deeper set of KSAs in the 
competency areas of requirements analysis and architecture design than the tester. A 
complete description of each of the roles identified above can be found in Appendix C: 
SSC Atlantic Engineering Department Role Descriptions. 
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Figure 15. Mapping Roles to sets of KSAs—Comparing Systems Engineering Role 

to that of a Tester 


D. SUBROLES OF THE SSC ATLANTIC SYSTEMS ENGINEER 

Just as there are KSAs common to all members of the SSC Atlantic Engineering 
Department, there are also KSAs common to all Systems Engineers. In May 2013, SSC 
Atlantic systems engineer “role champions” (those responsible for defining the KSAs 
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associated with the systems engineer role) identified KSAs common to all systems 
engineers at various CDM stages. Table 11 depicts these core systems engineer KSAs by 
competency area. 


Competency 

Vector 

Competency Area 

KSA 

stage 

Activity 

1.0 TECHNICAL BASIS FOR COST 

Ability to contribute to 
a Project Management 
Plan (PMP) 

Intermediate 

Activity 

1.0 TECHNICAL BASIS FOR COST 

Ability to Review and 
approve cost estimates 
for subsystem 
elements. 

Intermediate 

Activity 

5.0 REQUIREMENTS ANALYSIS 

Understands the 
characteristics of 
quality requirements 

Intermediate 

Activity 

5.0 REQUIREMENTS ANALYSIS 

Prioritizes requirements 
for system upgrades 
and future 

enhancements with the 
sponsor/customers, key 
stakeholders, and end 

users 

Advanced 

Activity 

6.0 ARCHITECTURE DESIGN 

Facilitates agreements 
among multiple 
stakeholders to resolve 
system interfaces and 
interoperability 

concerns. 

expert 

Activity 

16.0 TECHNICAL ASSESSMENT 

Executes continuous 
process improvements 
that enhance 
processes, products, 
and service quality. 

Intermediate 

Activity 

17.0 CONFIGURATION MANAGEMENT 

Basic ability to use 
configuration 
management tools for 
configuration 
management 

Entry 

Activity 

19.0 RISK MANAGEMENT 

Knowledge of and the 
ability to contribute to 
development of risk 
mitigation/contingency 
action plans 

Entry 
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Competency 

Vector 

Competency Area 

KSA 

stage 

Activity 

19.0 RISK MANAGEMENT 

Able to perform risk 
analysis 

Intermediate 

Activity 

23.0 ACQUISITION 

Serve on Source 
Evaluation Board (SEB) 
or as a Contracting 
Officer's Representative 
(COR) and have 
experience with 
development and 
implementation of 
contracts, procurement 
of major hardware or 
software situations 

Intermediate 

Activity 

30.0 SYSTEMS THINKING 

Able to define technical 
problem scope 

Intermediate 


Table 11. KSAs Common to All Systems Engineers 


There are a large number of project types for which a systems engineer at SSC 
Atlantic may be tasked to perform. Therefore, there are lots of different types of systems 
engineers. While there is a common set of KSAs associated with systems engineers, 
there are a number of KSAs that depend upon the subrole or specialty area of the systems 
engineer. Figure 16 defines the systems engineer subroles or specialty areas critical to 
the SSC Atlantic Engineering Department. Appendix D shows how role cards can be 
used to define and communicate each of the systems engineer subroles or specialty areas 
in terms of their basic role description/duties, key KSAs, typical employee job series, 
typical work products or deliverables, and recommended training. 



Role 

ITSM 

Speaalist 

SW 

Professional 

Technical 

Speaalist 

Architect 

Tester 


Systems 

Engineer 


lA 

Professional 


Mission 

Speaalist 


Specialty 


Data 

Professional 



Figure 16. SSC Atlantic Engineering Department Roles / 
Subroles of Systems Engineer 
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E. SSC ATLANTIC SE USE CASES 


An IPT at SSC Atlantic typically supports a number of related projects. IPTs are 
usually organized by common end item products and/or funding sponsors. For example, 
an IPT may focus entirely on wireless communications for the Navy, electronic security 
systems for the U.S. Marine Corps, or command center IT infrastructure for Joint 
services. The projects within an IPT may be highly correlated, where the end item 
product to be delivered by each project has a physical interface and interdependency with 
the products of the other projects. In this case, the IPT may even be delivering an 
integrated system of systems. In other cases, projects within an IPT are simply of a 
similar nature, but do not deliver interfacing end item products. In these cases, it is 
commonplace for an IPT to specialize in a family of systems that are routinely designed 
and delivered to multiple locations, but in similar configurations. 

Given the astounding number of IPT formations, IT domains and variations in 
system (or end item product) complexity, it would be very difficult to create a framework 
that satisfies all potential systems engineering use cases in full. However, by 
generalizing most of SSC Atlantic’s SE projects into five different use cases, one can 
understand some of the more common IPT perspectives on the role of a systems engineer. 
The following subsections examine these five use cases and some of their key 
competency areas. The figures provided with each of these use cases were developed in 
collaboration with John Lillard, SSC Atlantic Information Dominance Chief Architect. 
These images were used to help clarify various levels of abstraction in system complexity 
and SE project types. 

1. SE Use Case 1—Subsystem or Component Engineering and 
Assessments 

In this scenario, the project scope for an IPT would be to develop, procure or 
assess a new component or subsystem for use within a larger system. The engineering of 
the overall system is managed outside of the IPT’s project scope. An example would be a 
biometrics IPT which is tasked to assess facial recognition technologies to determine 
which one will provide the highest quality solution to meet the customer’s needs at the 
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best value to the government. Key competency areas associated with this use case 
include decision analysis as well as any number of competency areas within the 
technology competency vector (for example, sensors.) 
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Figure 17. SE Use Case 1—Subsystem or Component Engineering and Assessments 

2. SE Use Case 2—Systems Engineering (Simple System) 

In this scenario, an SSC Atlantic IPT would be tasked to develop and/or integrate 
a new capability in the form of a system, which is comprised of commercial-off-the-shelf 
(COTS) and/or government-off-the-shelf (GOTS) components integrated into a single 
capability. This type of system is typically used by a single organization or single 
mission. Key competency areas for this use case include stakeholder requirements 
definition, architecture design, verification and transition. 



Figure 18. SE Use Case 2—Systems Engineering (Simple System) 
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3. SE Use Case 3—Complex Systems Engineering 

Oftentimes, SSC Atlantic is tasked with fulfilling a customer capability gap that is 
more complex in nature and the basic problem at hand has not been solved in the past. In 
this case, SSC Atlantic may be tasked with developing and/or integrating a new 
capability in the form of a system. The scale of the system, its functions and interactions 
along with the diversity of the user base elevate the complexity of the effort. The 
resulting system is comprised of COTS and or GOTS components integrated into a large, 
multifunction capability. Key competency areas associated with complex systems 
engineering include requirements management, risk management, interface management, 
and integration. 



Figure 19. SE Use Case 3—Complex Systems Engineering 

System complexity plays a key role in delineating between SE Use Case 2 and 3. 
Table 11 depicts the key differences between basic or simple systems engineering and 
complex systems engineering as they apply to SSC Atlantic IT projects. 
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▼ Basic Systems Engineering 
■ Project Scope: 

• Standard design already exists 

• Systems Engineering effort 
only requires minor tailoring 
of design 

• System Complexity: 

■ Small # of components 

■ Few interactionsb/t 
components 

■ System will not evolve over 
time 

• iVimimaI to no external system 
interfaces 

■ Singular user base 

■ Focus is on a specific 
technology/product 

■ Single protocol 


T Complex System Engineering 

■ Project Scope: 

■ Requirements for a new or 
significantly upgraded 
capability exists 

■ No standard design already 
exists 

■ System Complexity; 

• Large # of components with 
many interactions b/t 
components 

■ System will evolve over time 

• At least one external interface 

■ Multiple St diverse 
stakeholders 

■ Focus on design/integration of 
multiple 

technologies/products 

■ Includes multiple protocols to 
ensure dissemination and 
receipt of info 


Figure 20. Comparison of Basic (Simple) SE and Complex SE 


4. SE Use Case 4—Platform Systems Engineering 

The SE use case for platform systems engineering focuses on the integration of 
systems into physical platforms to ensure that environmental, mounting, heat, power, 
lighting, network infrastructure, safety, ergonomics and/or survivability requirements are 
met. Physical platforms may include vehicles, ships, submarines, buildings, command 
centers and other physical structures in which IT systems and infrastructure may be 
integrated. This use case stresses the conduct of site or platform surveys (part of 
technical assessment), technical data package development (part of architecture design), 
technical planning, integration, validation and safety assurance. 
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Platform 



Figure 21. SE Use Case 4—Platform Systems Engineering 


5. SE Use Case 5—Systems of Systems (SoS) Engineering 

Some of the IPT efforts at SSC Atlantic are more focused on the methodology of 
systems of systems engineering rather than on the life cycle processes of conventional 
systems engineering. SoS engineering focuses on the planning, analyzing, organizing, 
and integrating of capabilities from a mix of existing and new IT systems into an SoS 
capability greater than the sum of the capabilities of the constituent parts. In addition to 
the tenets of traditional systems engineering, SoS engineering manages the complexity 
created by the cost, schedule and performance interdependencies of multiple independent 
programs that comprise the SoS. SoS engineering efforts are heavily grounded in the 
competency areas of systems thinking, enterprise architecture, interface management, risk 
management and, of course, SoS engineering. 
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Figure 22. SE Use Case 5—Systems of Systems Engineering 

F. COMPETENCY DEVELOPMENT AND ITS RELATIONSHIP TO 
SYSTEM COMPLEXITY 

Over the course of his or her career, a systems engineer will likely encounter 
projects that span more than one of the SE use cases described in Chapter IV, Section E. 
Eor example, a systems engineer may start out researching and assessing various IT 
components, then take on an assignment as a project engineer for a simple system, then 
grow into the role of a lead systems engineer for a complex system, and so forth. 
Generally speaking, a systems engineer will be assigned tasking that increases in system 
complexity over time. Not coincidentally, a systems engineer will develop KSAs across 
higher proficiency or developmental levels. This increase in competency and increased 
responsibility with more complex systems and projects go hand in hand. Figure 23 from 
Building a Competency Taxonomy to Guide Experience Acceleration of Lead Program 
Systems Engineers illustrates the notional progress a systems engineer would exhibit over 
the course of his or her career in terms of increased proficiency/competency and the 
responsibility of addressing situations and systems of increasing complexity. 
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Figure 23. Proficiency Level and Situational Complexity 
(From Squires et al., 2011, p. 7) 


Chapter IV, Section D defined several subroles for the role of a systems engineer. 
Each of these subroles bears its own set of KSAs at various proficiency stages and 
therefore, its own competency development model. Figure 24 depicts competency 
development progression for four subroles of the SE role—platform, communications, 
networks and technical management. This figure was developed in collaboration with 
John Lillard (SSC Atlantic) in order to illustrate how a SE competency development 
model provides a developmental roadmap for systems engineers in terms of 
competency/proficiency progression, increased project or system complexity and 
increased leadership responsibility. 
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V. A MODEL FOR EFFECTIVE SYSTEMS ENGINEERING 
WORKFORCE DEVELOPMENT AT SSC ATLANTIC 

A. EMPLOYING COMPETENCY DEVELOPMENT MODELS 

Defining the competency areas and KSAs required for SSC Atlantic systems 
engineers at various competency development levels and different use cases explains 
what types of KSAs need to be developed. However, if a systems engineer determines 
that he or she has a gap in KSAs in order to achieve his or her goals, then the competency 
framework can only tell them what the systems engineer is missing. In order to 
adequately employ a competency development model, one must recommend how KSAs 
can or even should be obtained. 

According to the naval SE CDM, KSAs can principally be obtained through the 
following developmental methods: 

• Education—Learned in a classroom environment as part of undergraduate, 
graduate or certificate programs 

• On the job training—Learned on the job 

• Professional development—Workshops or training sessions accomplished 
within an organization 

Using the basic KSA development methods defined by the naval SE CDM, four 
primary methods can be applied to SSC Atlantic: 

• Defense Acquisition University courses (educational training) 

• Graduate or certificate program (educational training) 

• SSC Atlantic-developed and provided training courses and/or workshops 
(professional development) 

• On the job training 

In an Internet post entitled “Education versus Training,” Geetha Krishnan (2008) 
makes the following assertions that help differentiate education (educational training) 
from training (professional development): 
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Education emphasizes first principles; training emphasizes application. 
Education focuses on building the mind; training on building skills. 


Most training is communication; hence the pizzazz. Presentation style is 
more important than instruetional rigor. Edueation, for the most part (refer 
the parenthetical point on the social act above), is content-driven. 

Most training is company-specifie; henee, not easily transferable from one 
job to another. Most education would be transferable. 

The learner for both education and training could be unwilling. But the 
learner for training is allowed to voice his thoughts and get the training / 
trainer ehanged. The onus of making training sueeeed is on the trainer or 
the organization; in education the learner takes a higher responsibility. As 
a corollary, if you don’t do well in edueation, you fail; if you don’t do well 
in training, the training failed (Krishnan, 2008). 

Each of these assertions may be, in fact, matters of Krishnan’s opinion; however, 
when the term “edueation” is replaced with “educational training” meaning 
undergraduate, graduate or certificate programs, then many analogies can be made. Eor 
example, SE graduate degree programs and the Certified Systems Engineering 
Professional (CSEP) eertification emphasize the prineiples, foeus on SE proeess life cycle 
eontent, and are transferable to a wide range of Industry and DoD organizations. When 
the term “training” is replaced with “professional development” or training/workshops 
accomplished within an organization such as SSC Atlantic, then similar analogies can be 
made. Generally speaking, SSC Atlantic-developed and delivered SE training is 
organization-specifie, is not as easily transferable from one organization to another, 
emphasizes the application of SE principles, and generally offers a more dynamic 
opportunity for feedback to the training instructor who is likely a practicing systems 
engineer moonlighting as a trainer. 
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B. THE ROLE OF DEFENSE ACQUISITION UNIVERSITY IN SE 

WORKFORCE DEVELOPMENT 

Most systems engineers at SSC Atlantic are either designated as being in a 
Defense Acquisition Workforce Improvement Act (DAWIA) Systems Planning, 
Research, Development and Engineering (SPRDE)-SE billet or have at least taken some 
of the associated DAU classes covered by the SPRDE-SE curriculum. The SPRDE-SE 
classes are a combination of computer-based and instructor-led training. Figure 25 shows 
a breakdown of the primary SPRDE-SE classes and the percentage of the learning 
objectives associated with each level of Bloom’s taxonomy (discussed in Chapter III). In 
this case, learning objectives are directly correlated to the KSAs that are targeted to be 
developed by each class. The far right column of Figure 25 shows what percentage of the 
naval SE CDM (shown here as the NPS SE COMP MOD) KSAs are associated with each 
level of Bloom’s taxonomy as well. Eigure 25 illustrates that, in general, DAU covers the 
knowledge and comprehension levels of Bloom’s taxonomy sufficiently. Therefore, for 
KSAs that are associated with basic DoD-generic (as opposed to SSC Atlantic-specific) 
knowledge and comprehension, it makes sense for DAU training to be the preferred KSA 
development method. 
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Figure 25. Cognitive Levels of DAU SPRDE-SE Level III Curriculum and NFS SE 

Competency Model (From Alexander, 2013, p. 42) 



It would be insufficient to look solely at the level of Bloom’s taxonomy when 
assessing the applicability of DAU classes to SE KSAs. One must also analyze the 
respective competency areas emphasized in the DAU SPRDE-SE classes to determine 
which are adequately addressed and which are not. Figure 26 depicts the number of 
DAU SPRDE-SE continuous learning/performance objectives (CL/POs) associated with 
each SE competency area. It should be noted that the competency areas of acquisition 
and risk management are appropriately covered by SPRDE-SE. In fact, Juli Alexander 
observes, “the DAU SPRDE-SE training curriculum is robust with regard to acquisition 
training. Approximately a third of the curriculum focuses on this essential competency” 
(2013, p. xvi). Technical planning in a broad sense is sufficiently covered as well, but 
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likely requires tailoring to show how it should be accomplished within an organization 
such as SSC Atlantic. Alexander also points out that the competency areas for safety 
assurance, system assurance, systems of systems, problem solving and strategic thinking 
show no “evidence of a strong link between the curriculum and the competency model... 
This would strongly demonstrate that the competencies in the model are not being 
addressed by the DAU SPRDE training curriculum” (2013, p. 53). It should also be 
noted that neither the technology nor the mission competency vectors are covered in 
SPRDE-SE. That being said, DAU offers a variety of SE classes in areas such as systems 
of systems, system assurance and other SE competency areas that are available DoD- 
wide but simply not included as part of the SPRDE-SE career track. 
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C. IN-HOUSE SE TRAINING CURRICULUM DEVELOPMENT 

When it comes to optimal methods for KSA development, the SEBoK states that, 
“traditionally, SE competencies have been developed primarily through experience, but 
recently, education and training have taken on a much greater role” (Pyster et al., 2012, 
p. 694). DAU provides SE and acquisition training to all of the DoD; therefore, much of 
the associated course material must be tailored for implementation at each DoD 
organization such as SSC Atlantic. For example, a SPRDE-SE class may provide the 
participant with knowledge regarding the key attributes of a sound requirement. 
However, that class will not specify which requirements management tools are to be used 
by the individual organizations, nor how specific requirements should be captured or 
documented. There are many cases such as this where the organization performing the 
work must develop or tailor its own SE classes in order to train the workforce on just how 
to execute these processes in a consistent manner. Systems engineers should also be 
educated on the specific SE tools used by their individual organizations. Examples of 
such tools include those associated with configuration management, risk management, 
requirements management and architecture design. 

The other major gap between what DAU has to offer and the SSC Atlantic 
competency framework KSAs lies in the technology competency areas. Since SSC 
Atlantic is an IT-centric command, networks, software applications, sensors and other 
technology areas must be well understood by its systems engineers. This training gap 
also points to the need to provide command-specific training. In the SSC Atlantic 
networks and communications department, senior leaders have already begun developing 
“Network University” classes in order to educate systems engineers (with a networks 
subrole/specialty) on the basics of Navy network architecture design. 

So how does one go about developing an “in-house” SE curriculum to address 
workforce/KSA development needs? GRCSE provides a process script for developing a 
curriculum for any competency, as shown in Table 12. From the steps highlighted in 
Table 12, a tailored SE curriculum development process for SSC Atlantic can be 
established. This approach would be considered a holistic approach to SE curriculum 
development. 
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1. Holistic Approach to SE Curriculum Development 

• Step 1: Establish SSC Atlantic SE competency framework (the analysis of 
existing competency models, prioritization of relevant 
competencies/KSAs, and defining proficiency levels/stages from Table 12 
Step 2) 

• Step 2: Prepare outcomes and objectives that align to the SSC Atlantic 
engineering process framework (this step tailored from Table 12 Step 3 
Bullet 1) 

• Step 3: Use outcomes and objectives to prepare SE curriculum in 4 basic 
modules: 

• Technical Management 

• System Design 

• Product Realization 

• Technologies & Missions 


Process Step 

Description 

Step 1: Establish the 
Development Team 

* Identify program stakeholders 

* Form team from stakeholders such as faculty responsible for curriculum 
design and representatives from prospective employing organizations. 

* Use a wide group of reviewers for each stage of development. 

Step 2: Create 
Competency Model 

* Study and analyze various competency models. 

* Choose or ada pt competencies appropriate to the stakeho Iders. 

* Defi ne proficie n cy leve 1 s. 

* Select target proficiency levels for each competency. 

Step S: Prepare Draft 
Curriculum 

* Based on competency model, prepare draft outcomes and objectives. 

* Use outcomes and objectives to prepare a draft curriculum. 

Step 4: Assess Draft 
Curriculum against 
Competency Model 

* For each competency, identify where in the curriculum it Is addressed and 
assess its summative proficiency level. 

* Aggregate and report on gaps between the "as is'^ and ''to be" proficiency 
levels. Also, report on problems with the competency model {e.g., 
imprecise descriptions of proficiency levels). 

Step 5: Evolve 
Curriculum and 
Competency Model 

* Based on the competency assessment report, identify curriculum 
elements that appear weak (e.g., entrance expectations, outcomes, 
objectives, curriculum architecture, the CorBoK, or individual course 
activities. 

* Determine required changes in the curriculum and implement them. 

* Modify the competency model based on the competency assessment 
report. 

* Repeat steps 4 and 5 after implementation to ensure continual evolution 
and improvement of the curriculum. 


Eigure 27. Process Script for Competency-based Curriculum Development. 

(From GRCSE vl.O, 2012, p. 109) 
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Taking a holistic or “top-down” approach can be effective in ensuring the breadth 
of competency area and KSA coverage in an in-house SE curriculum. However, the 
voice of the systems engineering workforce must also be truly heard in order to for the 
training strategy to be optimally effective. Once a holistic SE curriculum development 
strategy is established as summarized above, then a more grassroots approach should be 
taken to truly understand where SE skills have the greatest gap between supply and 
demand. 

2. Bottom-Up Approach to SE Curriculum Development 

• Step 1: Observe where employees lack knowledge of SE competency 
areas 

• Step 2: Generate training concepts to fill gaps 

• Step 3: Survey workforce to determine where training is most needed 

• Step 4: Research what classes DAU, SSC Pacific and others have to offer 

• Step 5: Decide which training classes need to be developed or tailored 

• Step 6: Use various SE forums, blogs and wikis to shape class learning 
objectives with participation from the SE workforce 

• Step 7: Recruit coalition of the willing and capable to develop and deliver 
training 

• Step 8: Pilot training class exercises and draft training material via 
informal forum events 

• Step 9: Develop final training content and aids (templates, checklists, 
process models) 

• Step 10: The willing and capable deliver training (then obtain feedback 
and recalibrate) 

When developing and delivering in-house training classes, here are a few training 
tips that have proven effective when delivering basic SE training classes at SSC Atlantic: 

• Digital response technology using radio frequency (RE) clickers can be 
used to gage audience understanding of key concepts throughout the class. 
Questions should be challenging and generate thoughtful discussion on 
key concepts. 

• Well-tailored individual and group exercises should be leveraged to ensure 
employees know how to apply key concepts. 
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• Defense Connect Online or other means of web-conferencing should be 
used to promote remote participation, collaborative exercises, polling, file 
sharing and class recordings. 

• “Easy” slides can be included in the training material to help employees 
gain course credit and professional development units or continuous 
learning points for continuing education. 

One final recommendation for the development and delivery of SE training 
courses is that the actual trainers should be practicing systems engineers themselves. 
Benefits of SE leaders developing SE course content and performing as SE trainers 
include the following: 

• Promotes knowledge sharing and collaboration 

• Provides ample opportunities for natural leaders to step up 

• Allows trainers to gain double continuous learning points (CLPs) 

• Typically results in cost savings over vendor-provided training 

• Tailors training classes toward “how SSC Atlantic does it” 

• Enables government control over course material 

• Sets distinct expectations for the audience that can be enforced by SE 
management 

• Promotes environment of continual learning 

• Enables rapid delivery of emergent processes and techniques 

• Allows trainers to truly master topics by teaching them 

D. DEVELOPING KSAS THROUGH OJT AND EORMAL EDUCATION 

Arguably, the best way to learn or develop KSAs is by doing. For that reason, 
OJT is ideal when it is possible and consists of a more knowledgeable, skilled and 
experienced systems engineer walking a less developed systems engineer through the 
execution of actual systems engineering. For this reason, SSC Atlantic has established 
formalized programs to encourage this type of knowledge transfer. During their first two 
years of employment at SSC Atlantic, junior systems engineers entering the workforce 
are encouraged to participate in rotational assignments on the order of three to six 
months, and these are designed to allow them to learn from more experienced systems 
engineers as well as provide worthwhile contributions to the associated projects and IPTs 
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More recently, SSC Atlantic has also started a job-shadowing program in which 
employees (not just systems engineers) can elect to shadow another senior employee for 
up to 16 hours in order for them to see how that individual approaches his or her job. 
This allows for employees at any point in their career to catch a glimpse at what it takes 
to perform in other positions within the organization as well as to get a better feel for 
which types of positions/jobs they might want to pursue later in their careers. They may 
also find that their “dream job” is not what they truly desire and thus allows them to more 
quickly adjust career goals to where their true passions can better align with 
organizational needs. 

A postgraduate degree in SE can significantly increase SE an individual’s 
competency level. Assuming that the employing organization will pay for at least a 
significant portion of the postgraduate degree cost, there are many factors to consider 
when an organization chooses to make such an investment. Typical SE Master’s degree 
program costs are in the $20,000 to $50,000 range, but can certainly cost significantly 
more or a little less. Without question, cost should be a major driving factor for an 
organization choosing to invest in a postgraduate degree program as there would be an 
advantage in affording to send two individuals through a degree program rather than one. 
The use of a cohort, in which several individuals from the same organization participate 
in the same degree program for a reduced cost, should also be encouraged. Cohorts also 
offer students/employees an opportunity to collaborate with one another within the same 
organization, which can add value and support to their experiences. In some cases, 
cohorts offer an additional opportunity for an organization such as SSC Atlantic (or its 
Echelon III parent command—Space and Naval Warfare Command) the opportunity to 
more significantly influence the scope of the classes offered in the program and/or the 
case study or thesis topics available to the students. 

Other critical factors influencing the selection of a SE degree program include 
scope and timing. A SE degree program should be selected which applies most directly 
to the scope of SE work being conducted within the organization as well as by the 
participating employees. In the case of SSC Atlantic, a degree program which features a 
focus on IT and naval systems would be more valuable than one that does not emphasize 
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these core elements of SSC Atlantic’s mission. Another critical factor for SE degree 
program selection is when the individual embarks on this effort during their career. 
GRCSE states, “Whether the student obtains work experience between completing a 
bachelor’s program and commencing master’s level studies is one of the most important 
factors in professional master’s level study’’ (GRCSE, 2012, p. 5). With respect to 
practicing systems engineers in the US and in Europe, GRCSE also points out that, “Eew 
obtain an undergraduate SE degree or study SE for their first master’s degree” (GRCSE, 
2012, p. 5). GRCSE goes on to recommend that at least two years of professional 
experience be obtained prior to pursuit of a master’s degree in SE. SSC Atlantic typically 
requires five years of professional experience as well as achievement of the target 
DAWIA certification level (for those in a DAWIA billet) prior to pursuit of a 
postgraduate degree funded by the organization. Other considerations for matching 
individuals with postgraduate SE degrees include the individual’s likelihood of remaining 
in the organization for a significant period of time, probability of the individual actually 
completing the graduate degree program, and the probability that the individual will 
actually apply what is learned to current and future projects. 

E. OTHER FORMS OF WORKFORCE DEVELOPMENT AND THE 
DEVELOPMENT OF LEADERSHIP SKILLS 

Job shadowing and rotational opportunities are two of the many opportunities for 
competency development within SSC Atlantic. When it comes to developing leadership 
skills such as external awareness, interpersonal skills and team building, programs such 
as the SSC Atlantic Mentorship Program and the Mid-Career Leadership Program 
(MCLP) can be very effective. The Mentorship Program offers a variety of different 
mentor-mentee engagement constructs—group mentoring (two mentors and eight 
mentees interacting at once), speed-mentoring (much like speed-dating) and classical 
one-on-one mentoring. As of July 2013, the Mentorship Program is in its second 
iteration of existence and continues to improve by providing a loosely-structured, yet 
objective-driven roadmap to fostering mentor-mentee relationships. The Mentorship 
Program is completely voluntary and allows mentor-mentee relationships to take form 
naturally. 
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The MCLP offers a much more intensive and structured learning environment for 
SSC Atlantic employees and, thus, it is much more competitive and time-consuming. 
The program lasts six months and only admits 20 participants each round. While the 
MCLP does not guarantee promotion, graduates are prepared to assume greater 
leadership roles and responsibilities. Many of the leadership skills highlighted in the SSC 
Atlantic competency framework are either directly or indirectly addressed by the 
program. 

F. IDENTIFYING WORKFORCE DEVELOPMENT METHODS EOR EACH 
KSA 

Figure 28 provides a decision tree which provides a recommended development 
method for different types of systems engineer KSAs. Although no distinction was made 
between basic and advanced in-house training, the assumption is that a basic in-house 
training session on a given competency area or set of KSAs would last four to eight hours 
with simple exercises, while a more advanced in-house training session would generally 
last forty hours or longer and would include more extensive “real-world” exercises. 
Appendix E provides recommended KSA development methods for each of the KSAs 
identified for a systems engineer. The leadership skills are excluded from this table, but 
are included in Appendix B. 
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KSAs 

(START) 



Figure 28. Decision Tree for Determining Which Developmental Method Should Be 

Used for Different Types of KSAs 


G. ASSESSING A SYSTEMS ENGINEER’S COMPETENCY LEVEL 

There are a variety of ways to assess whether a systems engineer has actually 
developed or attained a particular knowledge, skill or ability. The same can be said for 
assessment methods used as exit criteria for passing SE courses, since the intent of a SE 
course is to develop the KSAs of the participants. Some KSA assessment methods are 
very basic, easy to measure and only provide limited insight into the systems engineer’s 
true competency, such as the use of multiple-choice tests. Other assessment methods 
such as case study projects, oral exams or written essays are typically more labor- 
intensive and more subjective, yet offer additional insight into an individual’s depth of 
KSAs. GRCSE Appendix E provides a more exhaustive look into conducting an 
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assessment of SE KSAs and course learning objectives (GRCSE, 2012, p. 97). As of July 
2013, a proposal has been set forth to adopt a common competency development model 
assessment process across all of SSC Atlantic. This competency assessment process 
consists of individual’s assessing themselves against their role’s competency 
development model (CDM), submitting their CDM self-assessment and requested 
development/proficiency stage for official review, and a competency assessment board 
making the determination as to whether or not the individual has or has not achieved their 
asserted development/proficiency stage. If the board determines that the individual has 
not achieved their desired stage, then the board provides feedback to the employee as to 
which KSAs require additional development and basic recommendations on how to do 
so. Figure 29 depicts the proposed SSC Atlantic competency level assessment process as 
illustrated by Ann Rideout, Deputy Competency Lead for the SSC Atlantic Networks and 
Communications Engineering Department. 
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Figure 29. Competency Level Assessment Process 
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VI. CONCLUSION AND RECOMMENDATIONS 


A. FINDINGS 

Research question 1 asks what competency areas and associated KSAs are 
particularly applicable to SSC Atlantic systems engineers. In order to organize 
competency areas and KSAs into logical groupings, four competency vectors were 
established as depicted in Figure 12. Competency areas could then be defined and 
grouped under each competency vector. Each competency area could then be prioritized 
based on a standard set of SE use cases most commonly experienced at SSC Atlantic, as 
well as based on DoD and industry standards, as shown in Table 9. The high 
prioritization of competency areas associated with requirements, architecture design, 
software engineering and system assurance highlights the importance for sound up-front 
systems engineering process execution, IT systems’ increasing reliance on software and 
the paramount need for cybersecurity. As far as applicable KSAs within each 
competency area are concerned. Table 10 identifies KSAs core to the SSC Atlantic 
engineering department while Table 11 depicts the basic KSAs common to all systems 
engineers. By defining subroles (or specialty areas) for a systems engineer, further KSAs 
can be defined that stress certain competency areas over others. Figure 16 depicts 
example specialty areas associated with the systems engineer role. 

Research question 2 asks how GRCSE can be used to effectively employ a CDM. 
GRCSE provides a process script for competency-based curriculum development, as 
shown in Figure 27 from GRCSE vl.O. Chapter V, Section C of this thesis describes how 
SE curriculum development should optimally be accomplished by taking both a holistic 
(top-down) approach—tailored from GRCSE’s process script—as well as a bottom-up 
approach. The GRCSE-based top-down approach can be effective in training to the 
breadth of competency area and KSA coverage desired in a SE curriculum. A bottom-up 
approach can be effective in ensuring that the voice of the employee (the systems 
engineer in this case) is adequately heard as well and ultimately considered when 
establishing the SE training curriculum. 
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Research question 3 asks how various forms of education and training can best 
support the development of KSAs required to develop competent systems engineers at 
SSC Atlantic. Chapter V explores various forms of education and training that can be 
used to develop systems engineers, or in other words, train systems engineers on the 
KSAs needed in their CDM. Figure 28 provides a simple decision tree for determining 
when various forms of education and training may typically be most effective for 
developing KSAs in different competency areas or at different levels of Bloom’s 
taxonomy. Table 17 provides recommended development (or education and training) 
methods for each KSA defined in an SSC Atlantic systems engineer’s CDM. 

B. CONCLUSION 

In order to properly develop a SE workforce in an IT command such as SSC 
Atlantic, one must first understand what competency areas and KSAs systems engineers 
must attain. A SE competency framework should consider the SE life cycle processes, 
but also technology areas, mission/capability areas and leadership skills to ensure that 
systems engineers are well rounded in order to provide technical leadership to multi¬ 
disciplinary teams with role-diverse team members. When establishing a competency 
framework, careful consideration should be made toward which precise use case(s) will 
be supported by the framework. Not understanding the context and use of the 
competency framework can lead to a tremendous amount of KSA analysis that can be 
rendered useless or impractical. Identifying relevant and authoritative competency area 
and KSA sources for the competency framework is also critical, as there is no need to 
recreate data that has already been adequately developed by several other relevant and 
established industry and DoD organizations. In particular, the INCOSE, DAU SPRDE- 
SE, NASA and Navy SE competency models proved highly relevant to the execution of 
SE at SSC Atlantic. Due to SSC Atlantic’s mission focus on IT and cyberspace, the 
NIST national cybersecurity workforce framework also proved highly useful in tailoring 
a SE competency framework. 

When prioritizing competency areas and KSAs, each SE use case must be 
considered separately as each will likely emphasize different competency areas. 
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Competency areas such as stakeholder requirements definition, requirements analysis, 
architecture design, software engineering, acquisition, verification and system assurance 
require more emphasis at SSC Atlantic than others. In order to establish a complete set 
of KSAs at each competency development stage, a layered-cake approach should be 
taken, meaning that KSAs will be applicable to an increasingly narrowed sector of 
individuals. For example. Figure 30 shows how every SSC Atlantic employee needs 
leadership skills, members of the entire engineering department require “core” 
engineering skills, all systems engineers require a certain set of KSAs and then specific 
sub-roles or types of systems engineers require yet a separate set of KSAs. Each of these 
KSA sets is ultimately part of a systems engineer’s competency development model. In 
order to establish systems engineering roles that can be well understood across the 
organization, one must examine the roles that will interact with the role of an SE in order 
to determine where KSAs will be shared across the roles or unique to one or the other. 



Systems 
Engineer Role 

Engineering 

Department 


Leadership Skills (required for all) 


Eigure 30. SSC Atlantic SE Competency Eramework KSA Pyramid 

Simply understanding which KSAs are most critical to developing systems 
engineers is insufficient. Analysis must be conducted to understand how these KSAs can 
and should be obtained. There are a number of ways to develop SE KSAs. The most 
common methods are through educational training (DAU, degrees or certifications), in¬ 
house-developed training courses/workshops, and OJT. DAU SPRDE-SE classes can be 
effective when providing systems engineers with basic knowledge and comprehension of 
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the SE life cycle processes—particularly in the areas of acquisition and risk management. 
Leadership skills can be developed through programs such as the Mid-Career Leadership 
and Mentorship Programs. OJT can be enhanced when coupled with targeted rotational 
opportunities and job shadowing opportunities. If approached systematically, 
immeasurable value can be obtained from developing in-house SE training that engages 
systems engineers at all levels of the workforce. GRCSE provides useful, tailorable 
recommendations on how to develop and assess SE curricula. When it comes to 
assessing the competency of systems engineers, care must be taken to choose an 
assessment process and associated assessment methodologies that are relatively thorough 
yet not overly cumbersome, time-consuming and costly. 

C. FUTURE RESEARCH 

While the topic of SE workforce development has been heavily studied over the 
last decade, there are still a large number of related areas that need additional research 
and analysis. Those interested in furthering the subject of SE workforce development 
should consider KSA configuration management methods, competency framework 
management tools, and long-term SE career progression models. As more DoD and 
industry SE organizations embrace the use of competency models, the need to vet 
feedback and refine competency model KSAs will grow. As competency areas and 
KSAs evolve, recommendations should also be made on how systems engineers are re¬ 
certified to keep up with the latest principles and trends. Competency framework and 
KSA management tools could significantly reduce the burden of managing the 
recommended KSAs of the SE organizations as well as the KSAs specifically obtained by 
individual systems engineers; yet, they largely do not exist today. Publications such as 
GRCSE vl.O depict general career progression models for systems engineers; however, 
as SE competency frameworks become more stable and better understood by the greater 
SE workforce in the US, recommendations should be made as to specific, notional ways 
that systems engineers could and should pursue developing different KSAs and taking 
advantage of different opportunities over the course of their careers. Another area that 
could be further explored is the applicability of project management processes and IT 

topics from PMI and SEIA, respectively, to SE frameworks. 
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APPENDIX A. COMPETENCY MODEL USE CASE PROCESSES 


The following competency model use case process models/figures were 
developed in collaboration with the SSC Atlantic Workforce Management Office in order 
to better understand the context and uses of COM and KSA data. 



Figure 31. SSC Atlantic Organizational Capability Development 
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Figure 32. SSC Atlantic Individual Competency Development 



Figure 33. SSC Atlantic IPX Staffing Process 
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APPENDIX B. LEADERSHIP SKILLS 


The following leadership skills and associated indicators were tailored from the 
2011 version of Office of Personnel Management (OPM) leadership competency 
framework for use at SSC Atlantic. 


Leadership Skill / 
Personal Attribute 

Definition / Indicators 

stage 

Accountability 

Holds self and others accountable for measurable high- 
quality, timely, and cost-effective results. 

Intermediate 

Accountability 

Focuses on results and measuring attainment of outcomes. 

Intermediate 

Accountability 

Determines objectives, sets priorities, and delegates work. 

Intermediate 

Accountability 

Accepts responsibility for mistakes. 

Entry 

Accountability 

Complies with established control systems and rules. 

Entry 

Accountability 

Completes projects within areas of specific responsibility in 
a timely manner and within budget. 

Intermediate 


Communication— 

Oral 

Effectively and convincingly expresses information (for 
example, ideas or facts) to individuals or groups effectively, 
taking into account the audience and nature of the 
information (for example, technical, sensitive, 
controversial). 

Intermediate 

Communication— 

Oral 

Expresses oral information (i.e. ideas or facts) clearly, 
effectively, and with appropriate command of the English 
language. 

Entry 

Communication— 

Oral 

Listens effectively, including recognizing nonverbal cues. 
Clarifies information as needed. Seeks first to understand 
and then to be understood. 

Intermediate 

Communication— 

Oral 

Uses verbal and non-verbal communication to enhance 
message 

Entry 

Communication— 

Oral 

Facilitates an open exchange of ideas and fosters an 
atmosphere of open communication. 

Intermediate 

Communication— 

Oral 

Ensures timely connnunication, sharing information and 
concerns. 

Entry 

Communication— 

Oral 

Listens to others, attends to nonverbal cues, and responds 
appropriately. 

Intermediate 

Communication— 

Oral 

Creates and utilizes media (i.e. transparencies, PowerPoint, 
etc.) for presentations. 

Entry 

Communication— 

Oral 

Creates effective, organized presentations. 

Intermediate 

Communication— 

Oral 

Makes clear and convincing oral presentations; 

Intermediate 

Communication— 

Oral 

Listens to others, attends to nonverbal cues, and responds 
appropriately. 

Intermediate 

Communication— 

Oral 

Performs the process of offering information or data for 
consideration or display. 

Entry 
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Leadership Skill / 
Personal Attribute 

Definition / Indicators 

stage 

Communication - 
Written 

Recognizes and uses correct English grannnar, punctuation, 
and spelling. 

Entry 

Communication - 
Written 

Connnunicates written information (for example, facts, 
ideas, or messages) in a succinct and organized manner. 

Intermediate 

Communication - 
Written 

Produces written information, which may include technical 
material that is appropriate for the intended audience. 

Intermediate 


Conflict Management 

Identifies and takes steps to prevent potential situations that 
could result in unpleasant confrontations. 

Intermediate 

Conflict Management 

Manages and resolves conflicts, grievances, confrontations, 
or disagreements in a constructive manner to minimize 
negative personal impact. 

Advanced 

Conflict Management 

Applies appropriate rules and protocol for resolving 
conflicts. 

Advanced 

Conflict Management 

Formulates solutions to mitigate and resolve conflict. 

Advanced 


Continual Learning 

Assesses and recognizes own strengths and weaknesses 

Intermediate 

Continual Learning 

Pursues self-development 

Entry 

Continual Learning 

Grasps the essence of new information. 

Entry 

Continual Learning 

Masters new technical and business knowledge. 

Entry 

Continual Learning 

Seeks feedback from others and opportunities to master new 
knowledge. 

Entry 

Continual Learning 

Processes new information for later application. 

Intermediate 

Continual Learning 

Applies information learned. 

Entry 


Creativity/ 

Innovation 

Develops new insights into situations and applies innovative 
solutions to make organizational improvements. 

Intermediate 

Creativity/ 

Innovation 

Creates a work environment that encourages creative 
thinking, new ideas, and innovation. 

Intermediate 

Creativity/ 

Innovation 

Designs and implements new or cutting edge 
programs/processes. 

Advanced 

Creativity/ 

Innovation 

Questions conventional approaches 

Intermediate 

Creativity/ 

Innovation 

Develops new innovations, solutions, and insights. 

Entry 

Creativity/ 

Innovation 

Evaluates conventional approaches. 

Intermediate 


Customer Service 

Understands available products and services. 

Intermediate 

Customer Service 

Readily readjusts priorities to respond to pressing and 
changing client demands. 

Intermediate 
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Leadership Skill / 
Personal Attribute 

Definition / Indicators 

stage 

Customer Service 

Works with clients and customers (that is, any individuals 
who use or receive the services or products that your work 
unit produces, including the general public, individuals who 
work in the agency, other agencies, or organizations outside 
the Government) to assess needs, provide information or 
assistance, resolve their problems, or satisfy their 
expectations; 

Intermediate 

Customer Service 

Achieves quality end-products. 

Intermediate 

Customer Service 

Is committed to providing quality products and services. 

Intermediate 


Decisiveness/ Problem 
Solving 

Identifies and analyzes issues problems. 

Entry 

Decisiveness/ Problem 
Solving 

Makes sound, well-informed, objective decisions. 

Entry 

Decisiveness/ Problem 
Solving 

Understands the potential consequences and outcomes of 
different decisions. 

Intermediate 

Decisiveness/ Problem 
Solving 

Makes effective and timely decisions, even when data is 
limited or solutions produce unpleasant consequences. 

Advanced 

Decisiveness/ Problem 
Solving 

Is proactive and achievement oriented. 

Intermediate 

Decisiveness/ Problem 
Solving 

Connnits to action, even in uncertain situations, to 
accomplish organizational goals; causes change. 

Advanced 

Decisiveness/ Problem 
Solving 

Determines accuracy and relevance of information 

Intermediate 

Decisiveness/ Problem 
Solving 

Generates and evaluates alternatives to make 
recommendations. 

Intermediate 

Decisiveness/ Problem 
Solving 

Conducts scholarly or scientific investigation or inquiry to 
solve a problem or inquiry to enhance understanding. 

Intermediate 

Decisiveness/ Problem 
Solving 

Uses results to make appropriate recommendations or 
decisions. 

Intermediate 

Decisiveness/ Problem 
Solving 

Creates alternative solutions to address a problem. 

Intermediate 


Entrepreneurship 

Recognizes new opportunities. 

Entry 

Entrepreneurship 

Positions the organization for future success by identifying 
new opportunities. 

Intermediate 

Entrepreneurship 

Builds the organization by developing or improving 
products or services. 

Advanced 

Entrepreneurship 

Takes calculated risks to accomplish organizational 
objectives. 

Advanced 


External Awareness/ 
Political Savvy 

Identifies, understands, and keeps up to date on key national 
and international policies and economic, political, and social 
trends that affect the organization. 

Advanced 

External Awareness/ 
Political Savvy 

Evaluates the impact of pertinent issues. 

Advanced 
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Leadership Skill / 
Personal Attribute 

Definition / Indicators 

stage 

External Awareness/ 
Political Savvy 

Understands near-term and long-range plans and determines 
how best to be positioned to achieve a competitive business 
advantage in a global economy. 

Expert 

External Awareness/ 
Political Savvy 

Develops plans to achieve a competitive business advantage 
in a global economy. 

Expert 

External Awareness/ 
Political Savvy 

Identifies the internal and external politics that impact the 
work of the organization. 

Advanced 

External Awareness/ 
Political Savvy 

Approaches each problem or situation with a clear 
perception of organizational and political reality. 

Advanced 

External Awareness/ 
Political Savvy 

Recognizes the impact of alternative courses of action. 

Advanced 


Financial 

Management 

Applies understanding of organization’s financial processes 
necessary to ensure appropriate funding levels. 

Intermediate 

Financial 

Management 

Prepares, justifies, and/or administers the budget for the 
program area. 

Intermediate 

Financial 

Management 

Uses cost-benefit approaches to set priorities. 

Intermediate 

Financial 

Management 

Monitors expenditures and uses cost-benefit thinking to set 
priorities. 

Intermediate 

Financial 

Management 

Identifies cost-effective approaches. 

Intermediate 

Financial 

Management 

Applies procurement and contracting processes to programs 
and projects. 

Intermediate 

Financial 

Management 

Evaluates procurement and contracting processes. 

Advanced 

Financial 

Management 

Oversees procurement and contracting to achieve desired 
results. 

Advanced 


Flexibility/Resilience 

Is open to change and new information 

Entry 

Flexibility/Resilience 

Recognizes change in organizational conditions. 

Intermediate 

Flexibility/Resilience 

Adapts behavior and work methods in response to new 
information, changing conditions, or unexpected obstacles. 

Entry 

Flexibility/Resilience 

Effectively deals with ambiguity. 

Intermediate 

Flexibility/Resilience 

Deals effectively with pressure. 

Intermediate 

Flexibility/Resilience 

Maintains focus and intensity in ambiguous situations. 

Advanced 

Flexibility/Resilience 

Maintains focus and intensity in pressure situations. 

Intermediate 

Flexibility/Resilience 

Remains optimistic and persistent, even under adversity. 

Intermediate 

Flexibility/Resilience 

Recovers quickly from setbacks. 

Intermediate 

Flexibility/Resilience 

Effectively balances personal life and work. 

Intermediate 


Human Capital 
Management 

Builds and manages workforce based on organizational 
goals, budget considerations, and staffing needs. 

Advanced 
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Leadership Skill / 
Personal Attribute 

Definition / Indicators 

stage 

Human Capital 
Management 

Ensures that employees are appropriately recruited, selected, 
appraised, and rewarded 

Advanced 

Human Capital 
Management 

Recognizes performance problems. 

Advanced 

Human Capital 
Management 

Takes action to address performance problems. 

Advanced 

Human Capital 
Management 

Manages a multi-sector workforce and a variety of work 
situations. 

Advanced 


Information 

Management 

Identifies a need for and knows where or how to gather 
information. 

Intermediate 

Information 

Management 

Organizes and maintains information or information 
management systems. 

Intermediate 


Integrity/Honesty 

Creates a culture that fosters high standards of ethics. 

Advanced 

Integrity/Honesty 

Behaves in a fair and ethical manner toward others. 

Entry 

Integrity/Honesty 

Demonstrates a sense of corporate responsibility. 

Entry 

Integrity/Honesty 

Contributes to maintaining the integrity of the organization 

Entry 

Integrity/Honesty 

Displays high standards of ethical conduct and understands 
the impact of violating these standards on an organization, 
self, and others. 

Intermediate 

Integrity/Honesty 

Is trusted by others with tasks or information. 

Intermediate 


Interpersonal Skills 

Shows understanding, friendliness, courtesy, tact, empathy, 
concern, and politeness to others. 

Entry 

Interpersonal Skills 

Develops and maintains effective relationships with others. 

Intermediate 

Interpersonal Skills 

Effectively deals with individuals who are difficult, hostile, 
or distressed 

Advanced 

Interpersonal Skills 

Relates well to people from varied backgrounds and 
different situations. 

Intermediate 

Interpersonal Skills 

Considers cultural diversity, race, gender, disabilities, and 
other individual differences to determine appropriate 
courses off action or responses. 

Advanced 


Leadership / 

Influence / 

Negotiation 

Influences, motivates, and challenges others toward a 
common goal 

Intermediate 

Leadership / 

Influence / 

Negotiation 

Adapts leadership styles to a variety of situations. 

Advanced 

Leadership / 

Influence / 

Negotiation 

Persuades others to accept recommendations or cooperate. 

Advanced 

Leadership / 

Influence / 

Negotiation 

Builds consensus through give and take. 

Advanced 
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Leadership Skill / 
Personal Attribute 

Definition / Indicators 

stage 

Leadership / 

Influence / 

Negotiation 

Gains cooperation from others to obtain information and 
accomplish goals. 

Intermediate 

Leadership / 

Influence / 

Negotiation 

Works with others to reach an agreement 

Intermediate 

Leadership / 

Influence / 

Negotiation 

Negotiates to find mutually acceptable solutions. 

Intermediate 


Partnering/ 

Collaborative 

Performance 

Develops networks and builds alliances. 

Advanced 

Partnering/ 

Collahorative 

Performance 

Engages in cross-functional activities. 

Intermediate 

Partnering/ 

Collahorative 

Performance 

Collaborates across boundaries, and finds or achieves 
common ground with a widening range of stakeholders. 

Advanced 

Partnering/ 

Collahorative 

Performance 

Utilizes contacts to build and strengthen internal support 
bases. 

Intermediate 

Partnering/ 

Collahorative 

Performance 

Recognizes commonalities between individuals, groups, or 
stakeholder goals. 

Intermediate 


Self-Management 

Systematically monitors one’s own efforts and making 
appropriate modifications to ensure alignment with current 
or changing needs or goals. 

Intermediate 

Self-Management 

Recognizes changes that warrant behavioral adaptations. 

Intermediate 

Self-Management 

Sets well-defined and realistic personal goals. 

Entry 

Self-Management 

Displays a high level of initiative, effort, and commitment 
towards completing assignments in a timely manner. 

Entry 

Self-Management 

Works with minimal supervision. 

Intermediate 

Self-Management 

Controls own goal-directed behavior without innnediate 
external control. 

Intermediate 


Service Motivation 

Creates and sustains an organizational culture which 
encourages others to provide the quality of service essential 
to high performance. 

Advanced 

Service Motivation 

Enables others to acquire the tools and support they need to 
perform at a competent level. 

Advanced 

Service Motivation 

Shows a commitment to public service. 

Entry 

Service Motivation 

Aligns organizational objectives and practices with public 
interests. 

Expert 

Service Motivation 

Ensures that actions meet public needs. 

Advanced 
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Leadership Skill / 
Personal Attribute 

Definition / Indicators 

stage 

Service Motivation 

Influences others toward a spirit of service and meaningful 
contributions to mission accomplishment. 

Advanced 


Strategic 

ThinkingA^ision 

Formulates effective strategies consistent with the business 
and competitive strategy of the organization in a global 
economy. 

Expert 

Strategic 

ThinkingA^ision 

Examines policy issues and strategic planning with a long¬ 
term perspective. 

Expert 

Strategic 

ThinkingA^ision 

Determines objectives and sets priorities. 

Entry 

Strategic 

ThinkingA^ision 

Anticipates potential threats or opportunities. 

Intermediate 

Strategic 

ThinkingA^ision 

Envisions positive organizational possibilities. 

Advanced 

Strategic 

ThinkingA^ision 

Develops the necessary procedures and operations to 
achieve organizational possibilities. 

Advanced 

Strategic 

ThinkingA^ision 

Develops appropriate measures to evaluate achievement. 

Advanced 

Strategic 

ThinkingA^ision 

Understands where the organization is headed and how to 
make a contribution 

Intermediate 

Strategic 

ThinkingA^ision 

Takes a long-term view and recognizes opportunities to help 
the organization accomplish its objectives or move toward 
the vision. 

Advanced 

Strategic 

ThinkingA^ision 

Builds a shared vision with others. 

Advanced 

Strategic 

ThinkingA^ision 

Influences others to translate vision into action. 

Advanced 


Team Building 

Inspires and fosters team connnitment, spirit, pride, and 
trust. 

Intermediate 

Team Building 

Facilitates cooperation and motivates team members to 
accomplish group goals. 

Intermediate 

Team Building 

Consistently develops and sustains cooperative working 
relationships. 

Intermediate 

Team Building 

Encourages and facilitates cooperation and motivation 
within the organization and with customer groups to 
accomplish a common goal. 

Advanced 

Team Building 

Fosters commitment, team spirit, pride, trust. 

Advanced 

Team Building 

Develops capabilities in others through coaching, 
mentoring, rewarding, and guiding employees. 

Advanced 


Technical Expertise 

Uses knowledge that is acquired through formal training or 
extensive on-the-job experience to perform one's job 

Entry 

Technical Expertise 

Evaluates the technical sufficiency of work 

Advanced 

Technical Expertise 

Works with, understands, and evaluates technical 
information related to the job 

Intermediate 
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Leadership Skill / 
Personal Attribute 

Definition / Indicators 

stage 

Technical Expertise 

Advises others on technical issues. 

Expert 


Technology 

Credihility 

Applies principles, procedures, requirements, regulations, 
and policies related to specialized expertise. 

Expert 

Technology 

Credihility 

Understands linkages between administrative competencies 
and mission needs. 

Advanced 

Technology 

Credihility 

Addresses training and development needs. 

Advanced 


Technology 

Management 

Maintains knowledge concerning technological 
developments. 

Expert 

Technology 

Management 

Recognizes opportunities to integrate technology into the 
workplace. 

Intermediate 

Technology 

Management 

Integrates technology into the workplace to achieve results 
and improve program effectiveness. 

Advanced 

Technology 

Management 

Evaluates and plans for the impact of technological changes 
on the organization. 

Advanced 

Technology 

Management 

Creates and maintains an accessible, secure technology 
system. 

Advanced 


Table 12. Recommended Leadership Skills for Systems Engineers (After Office of 

Personnel Management, 2011) 


94 























APPENDIX C. SSC ATLANTIC ENGINEERING DEPARTMENT 

ROLE DESCRIPTIONS 


As of July 2013, the following eight primary roles have been defined within the 
SSC Atlantic Engineering Department (in addition to that of a systems engineer). An 
individual on an IPT may perform in one or more roles at any given time. These roles are 
subject to collapse into one another, expand or change in any way over time. 

• Technical Specialist —Configure, implement, deliver, administer, 
troubleshoot and support information technology (IT) systems and 
services. Paramount requirement is knowledge of IT principles, concepts, 
and methods; Within their areas of expertise, technical specialists advise 
and contribute to the design, development and implementation of solutions 
while ensuring compliance with relevant domain policies, processes and 
standards. Early in the solution lifecycle, they ensure mission relevancy, 
support needs and feasibility analysis, decompose specifications, 
recommend alternatives and inform critical design decisions. Later in the 
lifecycle, technical specialists contribute domain expertise within tests, 
support installations, evaluate the solution against design or performance 
requirements and recommend necessary improvements or corrections. 

• Enterprise Architect —Establishes and communicates mission and 
organizational needs; Develops and analyzes Concept of Operations; 
Defines capabilities, objectives, and measures of effectiveness 
(MOE)/measures of performance (MOP); Develops and evolves 
enterprise. System of Systems (SoS), and solution architectures; Conducts 
capability assessments and analysis; Develops, analyzes, and manages 
requirements; Identifies, defines and manages system interfaces; Assesses 
impacts of SoS and solution performance and upgrades; Conducts reviews 
and assessment focused on interoperability and management of risk; 
Manages strategic evolution of systems. 

• Software Professional —Applies a systematic, disciplined, quantifiable 
approach to the design, development, coding, operation, and maintenance 
of software, and the study of these approaches. 

• Data Professional —Responsible for the installation, configuration, and 
administration of database management systems or the management of 
data including architecture, analysis, and modeling. 

• Information Technology Service Management Specialist —Leads an 
integrated discipline for developing, improving and assuring the quality of 
IT services and their management systems. Focuses on optimizing 
processes, personnel, technologies and organizational structures 
contributing to standardization and enforcement of enterprise behavior 
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around the customer's desired capabilities and bound by defined 
performance measures conformant with relevant standards and 
frameworks to reduce Total Cost of Ownership (TCO) and assure mission 
accomplishment 

• Tester —Understands the intended purpose, operational context and 
concept of use of proposed systems. Plans and executes procedures to 
obtain, verify or provide data for the evaluation of progress in 
accomplishing developmental objectives, the performance, operational 
capability and suitability of systems, subsystems, component and 
equipment items, and their vulnerability and lethality. Verifies status of 
technical progress, verifies that design risks are minimized, substantiates 
achievement of contract technical performance, certifies readiness for 
initial operational testing (OT). Advises on testability of requirements and 
on risk involved in testing those requirements. 

• Information Assurance Professional —Conduct scientific and 

engineering activities that protect and defend information and information 
systems by ensuring their availability, integrity and confidentiality. These 
activities require expertise for the development and deployment of 
technical measures to protect and defend networks, cyber systems, 
computers, and information from disruption, denial, degradation, or 
destruction and for the restoration of information and information systems. 
Provide lA engineering expertise to support Information Operations 
capabilities 

• Mission Specialist —Uses a deep understanding of the context, 
characteristics and concepts of the customer's mission to define, guide 
and/or evaluate technical solutions that meet the operational needs of the 
user 
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APPENDIX D. SYSTEMS ENGINEER SUBROLE/SPECIALTY 

ROLE CARD SAMPLES 


A. ROLE CARD SAMPLE: SYSTEMS ENGINEER—TECHNICAL 
MANAGEMENT 


Specialty: Technical Management 

Identifies scope of engineering/technical tasks on an IPT. Determines the technical expertise and engineering 
processes required to support the IPT based on customer needs. Determine the roles/KSAs needed on an IPT and 
when to submit demand signals out to the appropriate competencies. Leads Technical Reviews (SETRs, etc.). 
Ensures proper review of engineering/technical deliverables produced by the project or IPT. Serves as the 
Engineering advisors for the IPT and adheres to latest Command Engineering initiatives. 

Note: The role of Systems Engineer—Technical Management may also be known as Lead Systems Engineer, 
Lead Systems Integrator, Technical Manager or Technical Lead _ 

Typical Series: Typical DAWIA Career Path: 

0800 Series Engineers, 1515 Operations SPRDE-SE 

Research Analysts, 1550 Computer Scientists _ 

Recommended Training: SE Planning, Intro to Requirements, Intro to Architecture, Systems Thinking, Intro 
to Complex Systems _ 

Typical Work Products: Systems Engineering Plan, Requirements Doc/Matrix, Design Plans, Interface 
Design/Ctrl Document, Work Breakdown Structure & Schedule Inputs _ 

Table 13. Systems Engineer—Technical Management Role Card Information 


COM Stage 

Competency Area 

Knowledge, Skill or Ability (KSA) 

Entry 

Stakeholder 

Requirements 

Definition 

Assists in defining the business and mission need for systems that will provide services, 
capabilities or platforms to end users and other stakeholders. 

Entry 

Requirements 

Analysis 

Analyzes, manages, and traces systems requirements. 

Entry 

Architecture Design 

Identifies systems interfaces and interoperability concerns. 

Intermediate 

Systems Thinking 

Demonstrates a broad understanding of the system context and environment 

Intermediate 

Architecture Design 

Ability to develop a preliminary subsystem design based on existing best practices 

Intermediate 

Architecture Design 

Ability to perform an Analysis of Alternatives (AoA) 

Intermediate 

Technical Planning 

Understands the role of systems engineering planning as part of an overall 
project/program plan 

Intermediate 

Technical Planning 

Knowledge of the command's global WBS 

Intermediate 

Technical 

Assessment 

Develops design review and milestone decision approaches 

Advanced 

Technical Planning 

Ability to develop a detailed Systems Engineering Plan 

Expert 

Technical 

Assessment 

Able to chair variety of technical review boards (e.g. PDR, CDR, TRR) 

Expert 

Integration 

Ability to identify and address issues associated with connecting multiple systems 
across organizational boundaries. 


Table 14. Systems Engineer—Technical Management Key KSAs 
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B. 


ROLE CARD SAMPLE: SYSTEMS ENGINEER—PLATFORMS 


Specialty: Platforms 

Provides engineering discipline in support of installing systems into a physical platform to ensure that 
environmental, mounting, heat, power, lighting, network infrastructure, safety, ergonomics and/or survivability 
requirements are met. Also ensures integration between system components. Primary process areas of interest 
include site surveys. Installation Design Plan and/or Technical Data Package development and review, BESEP 
creation, installation/integration oversight and PITCOs/SOVTs. 

Note: Platform Systems Engineer may also be known as Platform Engineer or Project Engineer _ 

Typical Series: Typical DAWIA Career Path: 

0800 Series Engineers _ SPRDE-SE _ 

Recommended Training: Site Surveys, SE Planning, Shore Installation Process Handbook, 
Intro to Technical Data Packages or Installation Design Plans, Analysis of Alternatives _ 

Typical Work Products: Systems Engineering Plans, Base Electronic Systems Engineering 
Plans, Assessment Reports, Site Survey Reports, Requirements Doc/Matrix Design Plans, 
System Operation Verification & Test Docs _ 

Sub-specialties: Ashore (Command Centers, Air Traffic Control Facilities, Fuel Handling 
Facilities, Electronic Security Systems, etc.). Vehicular, Afloat, Expeditionary, Subsurface, etc. 

Table 15. Systems Engineer—Platforms Role Card Information 


CDM Stage 

Competency Area 

Knowledge, Skill or Ability (KSA) 

Entry 

Requirements 

Analysis 

Analyzes, manages, and traces systems requirements. 

Entry 

Platforms 

Ability to use a checklist to review an Installation Design Plan (IDP) 

Entry 

Platforms 

Basic knowledge of computer, network and communications cabling and connectors 

Intermediate 

Stakeholder 

Requirements 

Definition 

Assesses key conditions, constraints, conflicting requirements, and organizational 
issues, including safety and security factors. 

Intermediate 

Platforms 

Knowledge/skill in shore installation/upgrade processes (e.g., the Shore Installation 
Process Handbook), including design, development, acquisition, documentation, CM, 
scheduling, resource management, site surveys, installations, system cutover. System 
Operational Verification and Testing (SOVT) & system turnover 

Intermediate 

Architecture Design 

Ability to perform an Analysis of Alternatives (AoA) 

Advanced 

Architecture Design 

Specify power supply and heating, ventilation, and air conditioning (HVAC) 
requirements and configuration based on system performance expectations and design 
specifications 

Advanced 

System Assurance 

Design and develop secure interfaces specifications between interconnected systems 

Advanced 

Requirements 

Analysis 

Recommends changes to systems requirements to align with government policy, and 
addresses future integration and interoperability challenges across programs or the 
enterprise. 

Expert 

Integration 

Ability to define SSC Atlantic product & platform integration policies 


Table 16. Systems Engineer—Platforms Key KSAs 


98 






















APPENDIX E. RECOMMENDED WORKFORCE DEVELOPMENT METHODS FOR EACH 

SYSTEMS ENGINEER KSA 


The following table displays each systems engineer KSA by competency vector, competency area and stage. The 


recommended development method for each KSA and the associated justification are shown in the far right columns of the table. 


Compete 

ncy 

Vector 

Competency Area 

KSA 

Stage 

Recom¬ 

mended 

Method 

Justification / Comments 

Activity 

GENERAL 

Basic knowledge of technical and technical 
mgt processes 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 

Activity 

GENERAL 

Knowledge of engineering/technical artifacts 
required by SSC Atlantic 

Entry 

in- 

house 

unique to SSC Atlantic 

Activity 

GENERAL 

Ability to review engineering/technical 
artifacts for completeness and quality 

Intermediate 

in- 

house 

unique to SSC Atlantic 

Activity 

1.0 TECHNICAL BASIS 

FOR COST 

Knowledge of SPAWAR accounting and 
financial systems 

Entry 

in- 

house 

unique to SSC Atlantic 

Activity 

1.0 TECHNICAL BASIS 

FOR COST 

Ability to contribute to timely and accurate full 
cost budget information (such as labor, 
procurement, travel estimates) to project 
managers when requested 

Entry 

in- 

house 

unique to SSC Atlantic cost 
estimation methods/tools 

Activity 

1.0 TECHNICAL BASIS 

FOR COST 

Ability to perform cost estimating on technical 
work products 

Entry 

OJT 

experiential developmental 
activities required 

Activity 

1.0 TECHNICAL BASIS 

FOR COST 

Ability to use Work Breakdown Structure 
(WBS) as a tool for tracking actual vs. 
estimated costs and use this information to 
revise cost models appropriately 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 
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Compete 

ncy 

Vector 

Competency Area 

KSA 

Stage 

Recom¬ 

mended 

Method 

Justification / Comments 

Activity 

2.0 MODELING & 

SIMULATION 

Knowledge of decision support tools, models, 
or simulations that are applicable to your job. 

Entry 

in- 

house 

unique to SSC Atlantic 
models, use cases 

Activity 

3.0 SAFETY 

ASSURANCE 

Understand and comply with safety strategies, 
policies, and standards 

Entry 

external 

vendor 

Not covered by DAU 

Activity 

3.0 SAFETY 

ASSURANCE 

Understands the relationship between 
reliability, availability, maintainability and 
safety 

Intermediate 

degree/ 

cert 

academia provides ample 
RAM material 

Activity 

4.0 STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Able to identify major stakeholders 

Entry 

in- 

house 

Stakeholder groups 
somewhat specific to SSC 
Atlantic 

Activity 

4.0 STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Understand the importance of requirements 
traceability 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 

Activity 

4.0 STAKEHOLDER 

REQUIREMENTS 

DEFINITION 

Can support the elicitation of requirements 
from stakeholders 

Intermediate 

OJT 

experiential developmental 
activities required 

Activity 

5.0 REQUIREMENTS 
ANALYSIS 

Understands that there are different types of 
requirements e.g. functional, non-functional, 
business etc. 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 

Activity 

5.0 REQUIREMENTS 
ANALYSIS 

Understands the Importance of managing 
requirements throughout the lifecycle 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 
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Compete 

ncy 

Vector 

Competency Area 

KSA 

stage 

Recom¬ 

mended 

Method 

Justification / Comments 

Activity 

5.0 REQUIREMENTS 
ANALYSIS 

Understands the need for quality 
requirements (achievable, verifiable, 
unambiguous, necessary and sufficient, 
complete, expressed as a need, consistent, 
and appropriate) 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 

Activity 

5.0 REQUIREMENTS 
ANALYSIS 

Contribute to decomposition of requirements 

Entry 

in- 

house 

requires tailored exercises; 
could also be done through 
OJT or degree/cert 

Activity 

5.0 REQUIREMENTS 
ANALYSIS 

Contribute to development of specification 
documents 

Entry 

OJT 

difficult to train 

Activity 

5.0 REQUIREMENTS 
ANALYSIS 

Understands the relationship between design 
and requirements 

Intermediate 

DAU 

could also leverage SE 
degree/cert 

Activity 

5.0 REQUIREMENTS 
ANALYSIS 

Ability to identify and analyze requirements 

Intermediate 

in- 

house 

requires tailored exercises; 
could also be done through 
OJT or degree/cert 

Activity 

6.0 ARCHITECTURE DE 

SIGN 

Basic knowledge of the different types of 
architecture 

Entry 

In- 

house 

unique to SSC Atlantic 
application of enterprise 
architecture discipline 

Activity 

6.0 ARCHITECTURE DE 

SIGN 

Identifies systems interfaces and 
interoperability concerns. 

Entry 

in- 

house 

basic ability could be 
covered by in-house 
training; otherwise - OJT 

Activity 

6.0 ARCHITECTURE DE 

SIGN 

Understands the need to explore alternative 
and innovative ways of satisfying the system 
need 

Entry 

in- 

house 

could also leverage SE 
degree/cert 
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Compete 

ncy 

Vector 

Competency Area 

KSA 

stage 

Recom¬ 

mended 

Method 

Justification / Comments 

Activity 

6.0 ARCHITECTURE DE 

SIGN 

Knowledge of the principles of architectural 
design and its role within the lifecycle 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 

Activity 

6.0 ARCHITECTURE DE 

SIGN 

Identify the basic elements/sections of an 
Technical Data Package (TDP) 

Entry 

in- 

house 

unique to SSC Atlantic 
approach to TDPs 

Activity 

10.0 VALIDATION 

Understands the purpose of validation 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 

Activity 

10.0 VALIDATION 

Understand structure and basic elements of a 
SOVT document 

Entry 

in- 

house 

SOVT is a tailored 
verification & validation 
concept 

Activity 

11.0 TRANSITION 

Aware of the type of activities required for 
transition to operation 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 

Activity 

12.0 SYSTEM ASSURA 

NCE 

Knowledge of Risk Management Framework 
(RMF) 

Entry 

TBD 

RMF is in process of being 
released 

Activity 

12.0 SYSTEM ASSURA 

NCE 

Knowledge of information assurance principles 
and tenets (confidentiality, integrity, 
availability, authentication, non-repudiation). 

Entry 

DAU 

could also leverage SE 
degree/cert 

Activity 

15.0 TECHNICAL PLAN 

NING 

Basic knowledge of technical 
disciplines/specialties applicable to SSC 

Atlantic 

Entry 

in- 

house 

unique to SSC Atlantic 

Activity 

15.0 TECHNICAL PLAN 

NING 

Knowledge of the command's global WBS 

Intermediate 

in- 

house 

unique to SSC Atlantic 

Activity 

15.0 TECHNICAL PLAN 

NING 

Able to tailor systems engineering processes 
to meet the needs of a specific 
project/program 

Intermediate 

OJT 

experiential developmental 
activities required 
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Compete 

ncy 

Vector 

Competency Area 

KSA 

stage 

Recom¬ 

mended 

Method 

Justification / Comments 

Activity 

15.0 TECHNICAL PLAN 

NING 

Understands the importance of planning, 
monitoring and controlling systems 
engineering activities 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 

Activity 

15.0 TECHNICAL PLAN 

NING 

Aware that common technical processes need 
to be planned 

Entry 

DAU 

well covered in DAU 

SPRDE-SE curriculum 

Activity 

16.0 TECHNICAL ASSES 

SMENT 

Able to (for a subsystem or simple project) 
monitor progress against plans 

Intermediate 

OJT 

experiential developmental 
activities required 

Activity 

16.0 TECHNICAL ASSES 

SMENT 

Identifies continuous process improvements 
that enhance processes, products, and service 
quality. 

Entry 

in- 

house 

In-house CPI training 
capability exists 

Activity 

16.0 TECHNICAL ASSES 

SMENT 

Aware of review types and their purposes 

Entry 

DAU 

well covered in DAU 
SPRDE-SE curriculum; 
however, there are SSC 
Atlantic unique review 
types as well 

Activity 

16.0 TECHNICAL ASSES 

SMENT 

Aware of activities to prepare for technical 
assessments 

Entry 

DAU 

well covered in DAU 
SPRDE-SE curriculum; 
however, there are SSC 
Atlantic unique review 
types as well 

Activity 

17.0 CONFIGURATION 

MANAGEMENT 

Knowledge and basic ability to perform 
configuration management activities 

Entry 

DAU 

knowledge can come from 
DAU, but ability through in- 
house /OJT 

Activity 

17.0 CONFIGURATION 

MANAGEMENT 

Aware of configuration change control 

Entry 

DAU 

well covered in DAU 

SPRDE-SE 
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Compete 

ncy 

Vector 

Competency Area 

KSA 

stage 

Recom¬ 

mended 

Method 

Justification / Comments 

Activity 

18.0 REQUIREMENTS 
MANAGEMENT 

Participate in (for a subsystem or simple 
project) documenting requirements in the 
proper format. 

Intermediate 

in- 

house 

unique to SSC Atlantic 
requirements 
documentation approach 

Activity 

18.0 REQUIREMENTS 
MANAGEMENT 

Knowledge of the Engineering Change 

Proposal (ECP) review process 

Entry 

in- 

house 

unique to SSC Atlantic ECR 
approach 

Activity 

18.0 REQUIREMENTS 
MANAGEMENT 

Knowledge of requirements management 
process. 

Entry 

DAU 

well covered in DAU 

SPRDE-SE 

Activity 

19.0 RISK MANAGEME 

NT 

Knowledge of and the ability to contribute to 
identification of risk, risk analysis, and risk 
monitoring 

Entry 

DAU 

risk mgt well covered in 

DAU SPRDE-SE 

Activity 

19.0 RISK MANAGEME 

NT 

Assists in executing the risk mitigation plan to 
ensure successful project and program 
completion. 

Entry 

OJT 

experiential developmental 
activities required 

Activity 

20.0 TECHNICAL DATA 

Ability to document and present lessons 
learned 

Entry 

OJT 

experiential developmental 
activities required 

Activity 

21.0 INTERFACE MAN 

AGEMENT 

Understands the need for interface 
management and its impact on the integrity of 
the system solution 

Entry 

DAU 

well covered in DAU 

SPRDE-SE 

Activity 

22.0 SOFTWARE 

ENGINEERING 

Basic understanding of software engineering 
principles 

Entry 

DAU 

well covered in DAU 

SPRDE-SE 

Activity 

23.0 ACQUISITION 

Ability to develop a Performance Work 
Statement (PWS) / Statement of Objectives 
(SOO) 

Intermediate 

in- 

house 

unique to SSC Atlantic 
PWS/SOO standards 
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Compete 

ncy 

Vector 

Competency Area 

KSA 

stage 

Recom¬ 

mended 

Method 

Justification / Comments 

Activity 

23.0 ACQUISITION 

Provides information for the Performance 

Work Statement (PWS) / Statement of 
Objectives (SOO) 

Entry 

OJT 

experiential developmental 
activities required 

Activity 

25.0 SYSTEM OF SYSTE 

MS 

Understands that SoS capability needs impact 
the system development 

Entry 

OJT 

experiential developmental 
activities required 

Activity 

30.0 SYSTEMS 

THINKING 

Able to describe the systems engineering 
lifecycle processes that are in place on their 
program 

Intermediate 

DAU 

well covered in DAU 

SPRDE-SE 

Activity 

30.0 SYSTEMS 

THINKING 

Able to define system boundaries and external 
interfaces 

Intermediate 

OJT 

experiential developmental 
activities required 

Activity 

30.0 SYSTEMS 

THINKING 

Aware of the influence the system has on the 
enterprise 

Entry 

OJT 

experiential developmental 
activities required 

Activity 

Data Engineering 

Awareness of data management and data 
storage concepts 

Entry 

external 

vendor 

training classes exist, but 
outside of SPRDE-SE 

Activity 

Enterprise 

Architecture 

Knowledge and understanding of the purpose 
and value of using architectures for 
requirements documentation; systems 
planning and investment decisions 

Entry 

in- 

house 

not well stressed in SPRDE- 

SE 

Activity 

Enterprise 

Architecture 

Knowledge of DoD enterprise architecture 
principles and reference models 

Intermediate 

in- 

house 

could also leverage SE 
degree/cert 
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Compete 

ncy 

Vector 

Competency Area 

KSA 

stage 

Recom¬ 

mended 

Method 

Justification / Comments 

Technolo 

gy 

Communications 

Basic knowledge of the characteristics of 
different communications systems 

Entry 

in- 

house 

could also leverage 
external vendor 

Technolo 

gy 

IT SERVICE 

MANAGEMENT 

Awareness DoD and DQN ITSM policies, 
guidance and core references 

Entry 

in- 

house 

SSC Atlantic maintains 
basic ITSM training 
capability 

Technolo 

gy 

Networks 

Knowledge of computer networking 
fundamentals 

Entry 

degree/ 

cert 

could also leverage 
external vendor 

Mission 

GENERAL 

Basic understanding of all Mission Areas / 
Domains 

Entry 

in- 

house 

could also leverage SE 
degree/cert for more in- 
depth knowledge 

Core to Systems Engineer 

Activity 

1.0 TECHNICAL BASIS FOR COST 

Ability to contribute to a 

Project Management Plan 
(PMP) 

Intermediate 

in-house 

Would show how a 

SE contributes to a 

PMP at SSC Atlantic 

Activity 

1.0 TECHNICAL BASIS FOR COST 

Ability to Review and approve 
cost estimates for subsystem 
elements. 

Intermediate 

QJT 

experiential 
developmental 
activities required 

Activity 

5.0 REQUIREMENTS ANALySIS 

Understands the characteristics 
of quality requirements 

Intermediate 

DAU 

well covered in 

SPRDE-SE 

Activity 

5.0 REQUIREMENTS ANALySIS 

Prioritizes requirements for 
system upgrades and future 
enhancements with the 
sponsor/customers, key 

Advanced 

QJT 

experiential 
developmental 
activities required 
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Compete 

ncy 

Vector Competency Area KSA 

stage 

Recom¬ 

mended 

Method Justification / Comments 



stakeholders, and end users 




Activity 

6.0 ARCHITECTURE DESIGN 

Facilitates agreements among 
multiple stakeholders to resolve 
system interfaces and 
interoperability concerns. 

expert 

OJT 

experiential 
developmental 
activities required 

Activity 

16.0 TECHNICAL ASSESSMENT 

Executes continuous process 
improvements that enhance 
processes, products, and 
service quality. 

Intermediate 

in-house 

In-house CPI 
training capability 
exists 

Activity 

17.0 CONFIGURATION MANAGEMENT 

Basic ability to use 
configuration management 
tools for configuration 
management 

Entry 

in-house 

unique to SSC 
Atlantic-specific 

CM tool(s) 

Activity 

19.0 RISK MANAGEMENT 

Knowledge of and the ability 
to contribute to development 
of risk mitigation/contingency 
action plans 

Entry 

in-house 

Must know how to 
do risk mgt lAW 
command 
policy/tool 

Activity 

19.0 RISK MANAGEMENT 

Able to perform risk analysis 

Intermediate 

DAU 

well covered in 

SPRDE-SE 

Activity 

23.0 ACQUISITION 

Serve on Source Evaluation 
Board(SEB) or as a 

Contracting Officer's 
Representative (COR) and 
have experience with 
development and 
implementation of contracts, 
procurement of major 
hardware or software 

Intermediate 

OJT 

experiential 
developmental 
activities required 
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Compete 

ncy 

Vector Competency Area 


Recom¬ 

mended 

Method Justification / Comments 


KSA Stage 







unique to SSC 



Able to define technical 



Atlantic technical 

Activity 

30.0 SYSTEMS THINKING 

problem scope 

Intermediate 

in-house 

scoping use cases 


Table 17. Recommended Development Method for Each Systems Engineer KSA 


108 





LIST OF REFERENCES 


Bloom B. S. (1956). Taxonomy of educational objectives handbook 1: The cognitive 
domain. New York: David McKay Co Inc. 

Bloom B. S. (n.d.). Bloom’s taxonomy of learning domains. 

http://www.nwlink.com/~donclark/hrd/bloom.html . Accessed July 20, 2013. 

Chestnut, H. (1967). Systems engineering methods. New York: Wiley. 

Checkland, P. (1993). Systems thinking, systems practice. New York: John Wiley & 

Sons. 

Daintith, J. (2009). A dictionary of physics. Oxford: Oxford University Press. 

Defense Acquisition University. (2012, October). Chapter 1.4 Defense Acquisition 
System. In Defense Acquisition Guidebook. 

https://acc.dau.mil/CommunitvBrowser.aspx?id=488292. Accessed July 26, 2013. 

Flagle, C., Huggins, W., & Roy, R. (1960). Operations research and systems 
engineering. Baltimore, MD: Johns Hopkins Press. 

Gelosh, D. (2009). What defines a systems engineer? Comparing and contrasting global 
perspectives on systems engineering competency. INCOSE Insight, 12(3), 2009: 
34. 

Holt, J. & Perry, S. A. (2011). A pragmatic guide to competency. Swindon, UK: British 
Informatics Society. 

Institute of Electrical and Electronics Engineers. (1998). IEEE Standard 1220: 

Application and management of the systems engineering process. New York: 
author. 

International Council on Systems Engineering. (2004). INCOSE systems engineering 
handbook. Seattle, WA: author. 

International Council on Systems Engineering. (2010). Systems engineering competencies 
framework 2010-0205. San Diego, CA: author. 

Jahangir, E. (2012, July). A framework to institutionalize systems engineering skill-set. 
22nd Annual INCOSE International Symposium, Rome, Italy. 

Krishnan, G. (2008, February). Education versus training. Simply speaking: on learning, 
business and beyond, http://simplv-speaking.blogspot.eom/2008/02/education- 
versus-training.html. Accessed July 8, 2013. 


109 






National Initiative for Cybersecurity Education. (2012). National cybersecurity workforce 
framework, http://csrc.nist.gov/nice/framework/. Accessed 8 July 2013. 

National Aeronautics and Space Administration. (2012). Project management and 
systems engineering competency framework v3.0. Washington, DC: author. 

Parker, S. (Ed.). (1994). McGraw-Hill dictionary of engineering. New York: McGraw- 
Hill. 

Pyster, A., Olwell, D., Hutchison, N., Enck, S., Anthony, J., Henry, D.,& Squires, A. 
(2012). Guide to the systems engineering body of knowledge (SEBoK) version 
1.0.1. Hoboken, NJ: The Trustees of the Stevens Institute of Technology. 

Pyster, A., Olwell, D., Ferris, T., Hutchison, N., Enck, S., Anthony, J., Henry, D., & 
Squires, A. (2012). Graduate reference curriculum for systems engineering 
(GRCSEE^). Hoboken, NJ: The Trustees of the Stevens Institute of Technology. 
www.bkcase.org/grcse/. 

Systems planning, research, development & engineering—Systems engineering/program 
systems engineering competency model. (2009). https://acc.dau.mil/adl/en- 
US/406181/file/54341/Competencv%20Model.pdf. Accessed May 30, 2013. 

Squires, A., Wade, J., Dominick, P., & Gelosh, D. (2011). Building a competency 

taxonomy to guide experience acceleration of lead program systems engineers. 
Ninth Annual Conference on Systems Engineering Research, Redondo Beach, 

CA. 

Space and Naval Warfare Command. (2013). SPAWAR systems engineering guidebook 
process framework. https://sseg- 

dev.spawar.navv.mil/se landing/home.isp?tabindex=l&index=search. Accessed 
July 26, 2013. 


110 








INITIAL DISTRIBUTION LIST 


1. Defense Technical Information Center 
Ft. Belvoir, Virginia 

2. Dudley Knox Library 
Naval Postgraduate School 
Monterey, California 


111 



